[llvm-dev] libc++ failed to link against musl

Dmitry Golovin via llvm-dev llvm-dev at lists.llvm.org
Wed Jun 7 02:49:36 PDT 2017

07.06.2017, 12:14, "David Chisnall" <david.chisnall at cl.cam.ac.uk>:
> On 6 Jun 2017, at 21:41, Dmitry Golovin <dima at golovin.in> wrote:
>>  Neither is the case. The system that I want to build with this toolchain is Linux-based, but not GNUish. I would like to use musl instead of glibc and libc++ instead of libstdc++, only use binutils provided by LLVM. I think that in that case I will link libc++abi and libunwind to libc++ statically, so I will not have to add -lunwind and -lc++abi to my LDFLAGS. Is it okay to do that? There is an experimental LIBCXX_ENABLE_STATIC_ABI_LIBRARY option, I will try to enable it.
>>  The host system that I'm compiling on is Alpine Linux (musl-based distro), if it matters.
> It probably makes sense for libc++abi or libcxxrt, but it makes less sense for libunwind because C libraries that need to interoperate with C++ will link with this (by default assuming libgcc_s.so provides the relevant symbols). If both do then you’re going to have conflicts, if libgcc_s.so or equivalent doesn’t then you’re going to have link failures in pure-C programs that use C/C++ compatible libraries.
> David

As far as I can understand, all the functions of libgcc are provided by compiler-rt and libunwind, so it is possible to build a toolchain that will not have any parts of GCC at all. For now my toolchain can only produce statically liked binaries, I have some trouble with shared (https://bugs.llvm.org/show_bug.cgi?id=32425#c8), and it only works for C, the C++ test program segfaults.


More information about the llvm-dev mailing list