Compilation fails on aarch64 about rcpptoml

[andresrcs]

I was wrong this is not related to g++ / gcc since with version 12 compilation fails as well on aarch64. Now I think it is related to the TOML++ version used as per this GH issue

marzer/tomlplusplus#178

[eddelbuettel]

Please try the main branch now. I also heard from the fellow Debian maintainer looking after this package there, and saw it failing on CRAN for e.g. i386. After discussing with upstream it became clear I should just set TOML_ENABLE_FLOAT16=0 (which the previous code / code in the 2.0 release tried to determine heuristically).

[andresrcs]

Compilation works now! Tested on Raspbian OS and Ubuntu 22.04 LTS.

Any estimate for availability on CRAN?

[eddelbuettel]

My apologies for sleeping on this when you first reported it. Should be fixed on CRAN by tomorrow.

[eddelbuettel]

Hm, I am on Ubuntu 22.10 here which I upgrade every six months, and I still have g++-10 here -- it comes up as 10.4.0.
With that I install the package just fine:

edd@rob:~/git/rcpptoml(master)$ install.r
* installing *source* package found in current working directory ...
* installing *source* package ‘RcppTOML’ ...
** using staged installation
** libs
g++-10  -std=gnu++17 -I"/usr/share/R/include" -DNDEBUG -I../inst/include -I'/usr/local/lib/R/site-library/Rcpp/include'    -fpic  -g -O3 -Wall -pipe -pedantic -Wno-ignored-attributes  -c RcppExports.cpp -o RcppExports.o
g++-10  -std=gnu++17 -I"/usr/share/R/include" -DNDEBUG -I../inst/include -I'/usr/local/lib/R/site-library/Rcpp/include'    -fpic  -g -O3 -Wall -pipe -pedantic -Wno-ignored-attributes  -c parse.cpp -o parse.o
g++-10 -std=gnu++17 -Wl,-S -shared -L/usr/lib/R/lib -Wl,-Bsymbolic-functions -flto=auto -ffat-lto-objects -flto=auto -Wl,-z,relro -o RcppTOML.so RcppExports.o parse.o -L/usr/lib/R/lib -lR
installing to /usr/local/lib/R/site-library/00LOCK-rcpptoml/00new/RcppTOML/libs
** R
** inst
** byte-compile and prepare package for lazy loading
** help
*** installing help indices
** building package indices
** testing if installed package can be loaded from temporary location
** checking absolute paths in shared objects and dynamic libraries
** testing if installed package can be loaded from final location
** testing if installed package keeps a record of temporary installation path
* DONE (RcppTOML)
edd@rob:~/git/rcpptoml(master)$ 

So this would point so something local to your Raspberry Pi. One thing you should be able to do too is to stick with the previous version that was using another (older) TOML C++ library,

[andresrcs]

May be specific to Raspberry Pi OS but not to my single Pi since other people are experiencing the same problem. I can personally stick to the previous version as long as no other packages depend on the new one but this brings problems in other scenarios. For example, the R4Pi project provides precompiled binaries for Raspberry Pi OS and a package repository that can't update certain packages is not that useful.

@sellorm do you have any additional details to contribute to this issue report?

[eddelbuettel]

Well yes while it sucks when confronted with it (I too was once forced to survive on an old CentOS ...) and I can say here is that "that's life". C++17 is permitted at CRAN, and other packages use it / more oackages will use it going forward.

My $atwork package will switch to C++20 in the spring. These things do require toolchain updates every now and then.

[eddelbuettel]

That's what I get for switching libraries: "new bugs". Sorry about that. I hope it gets sorted out. It is a more powerful library but as the saying goes, "nothing in life is free".

[andresrcs]

FWIW, I have confirmed this is not specific to Raspberry Pi but to the aarch64 architecture in general. Compilation also fails on Ubuntu 22.04 LTS aarch64 on an Ampere Altra machine

[eddelbuettel]

You were early. I now have a failure on arm at CRAN, a failure on i386 at CRAN (care less but still matters) and Debian has build woes too. I'll follow up with upstream.

[eddelbuettel]

RcppTOML 0.2.1 is now on CRAN, so we can close this.