Use libc++ on fedora-clang-devel

[nealrichardson]

CRAN uses a custom clang that uses libc++ on this test machine. If you build any dependencies and don't use that clang, the build may fail with undefined symbols errors (such as this). In apache/arrow#7694 I patched the rhub image we use in CI to force libc++, 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.

[gaborcsardi]

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.

[gaborcsardi]

We could have another image that is built with libc++, though. I am reworking all images soon, so let's keep this open.

[nealrichardson]

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?

[gaborcsardi]

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.