Clang doesn't have a C++ stdlib that works on GNU/Linux. I'm sure that could change, but it's unlikely to be a priority for Apple employees, and LLVM's libc++ is developed by and for Apple.
Switching a distro to use clang-with-libstdc++ doesn't remove the dependency on GCC but adds a dependency on a combination that isn't properly supported by the vendor of clang or by libstdc++ upstream. That combination is likely to be fragile without an influx of libstdc++ contributors who care about clang, so any distro making the switch would need to do the work themselves, rather than expecting upstream GCC maintainers to help a non-copyleft compiler steal our lunch.
Posted Mar 29, 2012 12:47 UTC (Thu) by gowen (guest, #23914)
[Link]
Absolutely, this was the showstopper for me, last time I tried clang. Any C++ header that (implicitly) included <type_traits> (IIRC) barfed on the fact that in the g++ headers these are implemented with use g++'s variadic macro support. That rules out (among other things) a fair few STL containers like <map>.
Distributions looking at LLVM
Posted Mar 29, 2012 20:15 UTC (Thu) by mathstuf (subscriber, #69389)
[Link]
FYI, I'm using clang 3.1 (svn snapshot) just fine with Boost versions 1.44.0 through 1.49.0 (Python, Filesystem, Threads, Graph, and other libraries) and the codebase itself uses quite a few STL containers. I haven't tested 3.0 (older Boosts aren't compiling with GCC 4.7.0, so testing is harder) and 2.8 chokes on Boost.
Distributions looking at LLVM
Posted Mar 30, 2012 12:17 UTC (Fri) by jwakely (subscriber, #60262)
[Link]
(I assume you mean variadic templates, not macros.)
Some time ago Fedora shipped a version of clang (2.8 IIRC) that was completely incompatible with the system GCC headers, which was silly - they should have shipped an older libstdc++ (alongside the system one) just for use by clang. Clang 3.0 and later has far fewer issues and work well with all but the very bleeding-edgiest libstdc++ headers.