(In reply to comment #43) > (In reply to comment #42) > > OpenMandriva has successfully changed the compiler to clang (3.7.1 for now, > > will update to 3.8 as it is released), but decided to stick with libstdc++ > > to preserve binary compatibility with other Linux distributions -- users > > want to run non-open source stuff like steam, and that stuff doesn't get > > built for OSes that don't have a giant user base. > > If you ship GCC at all, and if that happens to be 5.x, and you happen to > choose to enable the CXX11 ABI by default, you'll run into the exact same > problem. Doesn't matter who's on top. > > > > OpenMandriva could switch system libraries etc. to libc++, but even then > > problems would likely arise (e.g. binary-only application links to Qt and > > expects Qt to be linked to libstdc++ -- the only "fix" would be providing 2 > > different versions of all C++ libraries and even then things would likely > > break, with e.g. libstdc++-Qt not being able to load style plugins built for > > libc++-Qt and vice versa, so custom installed widget themes wouldn't work > > for binary-only applications). > > That, in addition to multilib/multiarch will be a major pain for all > distros. This really isn't a solution. > > > > So yes, there indeed is a use case for building the entire OS with clang but > > not libc++ until we get to a point where relevant closed source stuff > > switches to libc++ (or better yet, gets open sourced so people can link it > > to any STL they like). > > Even if the day Clang and libc++ become the top dog on most Linux > distributions ever comes, we'll still have to cope with legacy GCC and > libstdc++ for a good number of decades from then on. > > Coexisting is the only solution for this century.
As a practical manner, we'll never be able to compile all of our existing code against libc++, unless libc++ decides to implement the not-insignificant set of libstdc++ extensions (e.g. everything under __gnu_parallel::, _gnu_cxx::stdio_filebuf) [https://gcc.gnu.org/onlinedocs/libstdc++/manual/extensions.html]. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to llvm-toolchain-3.6 in Ubuntu. https://bugs.launchpad.net/bugs/1488254 Title: clang++ no longer ABI-compatible with g++ Status in LLVM: Confirmed Status in llvm-toolchain-3.6 package in Ubuntu: Confirmed Bug description: $ cat foo.cc #include <string> std::string hello = "Hello, world!\n"; $ cat bar.cc #include <string> #include <iostream> extern std::string hello; int main() { std::cout << hello; return 0; } $ g++ -c foo.cc && g++ foo.o bar.cc && ./a.out Hello, world! $ clang++ -c foo.cc && clang++ foo.o bar.cc && ./a.out Hello, world! $ g++ -c foo.cc && clang++ foo.o bar.cc && ./a.out /tmp/bar-34fb23.o: In function `main': bar.cc:(.text+0x14): undefined reference to `hello' clang: error: linker command failed with exit code 1 (use -v to see invocation) $ clang++ -c foo.cc && g++ foo.o bar.cc && ./a.out /tmp/ccqU38Mh.o: In function `main': bar.cc:(.text+0x5): undefined reference to `hello[abi:cxx11]' collect2: error: ld returned 1 exit status In practice, this means that many programs using C++ libraries other than libstdc++ fail to compile with clang++. For example, mosh fails with undefined references to google::protobuf::internal::empty_string_, google::protobuf::MessageLite::InitializationErrorString() const, and google::protobuf::MessageLite::SerializeAsString() const. To manage notifications about this bug go to: https://bugs.launchpad.net/llvm/+bug/1488254/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
