Differential D96070
[clang] [driver] Enable static linking to libc++ Authored by tbaeder on Feb 4 2021, 11:45 AM.
Details Hi, currently the following fails: clang++ -stdlib=libc++ -static ./test.cpp because libc++ needs libc++abi and pthreads. This change has already been proposed in a different version, using -static-libc++ in https://reviews.llvm.org/D63329 And https://reviews.llvm.org/D60794 tried to do it in libc++ instead of clang. This version makes both linking with -static as above work, as well as -static-libstdc++ -stdlib=libc++.
Diff Detail
Unit Tests Event TimelineComment Actions I'm not convinced that this is the right way of handling it. Libc++ can be used on top of a number of C++ ABI libraries (both libsupc++/libstdc++ and libcxxabi), and how they are linked varies with how a toolchain is assembled. In particular, if libcxx is built with LIBCXX_ENABLE_STATIC_ABI_LIBRARY enabled, the libcxxabi static library is merged into libc++.a, making static linking work just fine. Comment Actions It is difficult for clang driver to make the decision because libc++ has multiple C++ ABI implementations as @mstorsjo said. Persoanlly (https://maskray.me/blog/2020-12-12-c++-exception-handling-abi#use-libc-and-libcabi) I use: clang++ -stdlib=libc++ -static-libstdc++ -nostdlib++ a.cc -Wl,--push-state,-Bstatic -lc++ -lc++abi -Wl,--pop-state -pthread This is still a bit inferior because there is a duplicate -lc++ passed by the driver. Dynamically link against libc++.so (which depends on libc++abi.so) (additionally specify -pthread if threads are used): Comment Actions The goal here is for distributions to be able to build libc++ one way and then have it work with clang without requiring that users add additional linker flags besides -static or -stdlib=libc++. Is there a combination of CMake arguments we can use when building libc++ to make all static and shared linking with libc++ work out of the box? Comment Actions I can't test this right now, but it is manually specifying pthread not needed in that case? Are you suggesting clang should do the same? Or should clang just not do anything here and people should be aware they need to pass additional flags when using libc++ (on Linux)? Comment Actions I can't speak for other systems, but forcing libpthread to be linked is in general not desirable as it creates a non-trivial runtime cost, especially when <thread> is not used. That's still a pretty common use case of C++. Comment Actions The problem is that we have -lc++ (optional -lc++abi/-lcxxrt/others) (optional -lpthread)) dependency. While we can control -lpthread with -pthread (which does extra things on its own), we cannot control (optional -lc++abi/-lcxxrt/others), which is depended by the installation configuration (e.g. LIBCXX_STATICALLY_LINK_ABI_IN_STATIC_LIBRARY, or libc++.a as a linker script (https://bugs.llvm.org/show_bug.cgi?id=46321), or .deplibs) and whether you are specifying --sysroot. Perhaps I had the opportunity to redesign the matter, I would let -stdlib=libc++ not affect linker options at all. Users just should specify -lc++ and related options by themselves. Comment Actions Right, but at least some of these sound like the can or should be solved in libc++ then. Reading https://reviews.llvm.org/D60794, I thought this was not going to happen and the solution should instead be in clang. What is the ideal solution here? If -static -stdlib=libc++ is not meant to work, is the working solution documented anywhere that we could link people to? If your blog post isn't official of course :) Comment Actions I think the root cause of the push back you're getting is that this is normally handled by vendors when they decide how they're going to ship libc++ on their platform or in their toolchain. For example, on Apple platforms, we ship libc++.dylib, and we make sure to re-export libc++abi.dylib's symbols from libc++.dylib. The result is that you only need to specify -lc++ (which the compiler does by default), and everything "works". Since we don't ship libc++.a, there's no out-of-the-box solution to make it work - it's not officially supported. Some folks do diverge from that, however we assume they are willing to get their hands dirty and use the flags required to make it work (i.e. -lc++ -lc++abi). My understanding is that the same goes for other platforms, where each has their preferred way of shipping libc++. If we were to officially ship libc++.a in the SDKs for Apple platforms, I could imagine that we'd want to merge libc++abi.a into libc++.a, and there again you'd only need to specify -static -lc++ and everything would work (unless I'm missing something). Making that work out-of-the-box would be something we'd want to achieve in how we're building and shipping libc++, not by modifying the behaviour of the Clang driver on multiple platforms. The TL;DR of what I wrote above is that I believe this is the correct answer. My main area is Apple platforms and not Linux, though, so this is just my .02 as someone who ships libc++. Comment Actions Making -stdlib=libc++ not affect linker option for -static and -static-pie looks good to me, for the GNU toolchain. They are expected to pass -lc++ -lc++abi if they use separate libc++abi.a. |