Open nealrichardson opened 4 years ago
I am not comfortable merging this, because I am not sure if libc++ and libstdc++ are ABI compatible. It seems that even a std::string
is different in the two, so you cannot pass a std::string
from a library that uses libstdc++
to a program that uses libc++
?
CRAN's Fedora machine has custom installed libraries that are built with libc++
, but this image does not.
We could have another image that is built with libc++, though. I am reworking all images soon, so let's keep this open.
I am not comfortable merging this, because I am not sure if libc++ and libstdc++ are ABI compatible.
Isn't that the point though? Adding this exposed the ABI incompatibility issue that CRAN was revealing. Or are you concerned that unless this change is done at a lower level, there will be spurious ABI issues?
Or are you concerned that unless this change is done at a lower level, there will be spurious ABI issues?
Yeah. It is clear that the R-hub image is mostly useless, at least in replicating what CRAN has. When I wrote it there was no information about CRAN's Fedora whatsoever, except that it was clang. But of course clang or g++ does not matter much, what matters in libc++.
I am starting to write new images soon, so I'll do this then.
CRAN uses a custom
clang
that useslibc++
on this test machine. If you build any dependencies and don't use thatclang
, the build may fail with undefined symbols errors (such as this). In https://github.com/apache/arrow/pull/7694 I patched the rhub image we use in CI to forcelibc++
, as proposed here, which reproduced my error.There's probably a more elegant way to do this, but it seemed to work. Also, https://www.stats.ox.ac.uk/pub/bdr/Rconfig/r-devel-linux-x86_64-fedora-clang mentions other config/flags that maybe should be set in this image, but I didn't need to deal with that to reproduce and fix my issue.