David Chisnall via llvm-dev
2017-Jun-06 17:40 UTC
[llvm-dev] libc++ failed to link against musl
On 5 Jun 2017, at 15:17, Jonathan Roelofs via llvm-dev <llvm-dev at lists.llvm.org> wrote:> > On 6/5/17 5:17 AM, Dmitry Golovin via llvm-dev wrote: >> I'm trying to build LLVM, Clang, LLD, compiler-rt, libc++, libc++abi and libunwind with musl-based toolchain. >> >> The configuration is the following: >> >> LIBCXX_HAS_MUSL_LIBC=ON >> LIBCXX_HAS_GCC_S_LIB=OFF >> CLANG_DEFAULT_CXX_STDLIB=libc++ >> CLANG_DEFAULT_LINKER=lld >> CLANG_DEFAULT_RTLIB=compiler-rt >> LLVM_DEFAULT_TARGET_TRIPLE=x86_64-pc-linux-musl >> LLVM_TARGET_ARCH=x86_64 >> LLVM_TARGETS_TO_BUILD=X86 >> >> When linking libc++.so there are a lot of undefined references to __cxa_allocate_exception, __cxa_begin_catch, __cxa_end_catch, __cxa_free_exception, __cxa_guard_abort, __cxa_guard_acquire, __cxa_guard_release, __cxa_pure_virtual, __cxa_rethrow, __cxa_throw, __gxx_personality_v0, _Unwind_Resume, vtable for __cxxabiv1::__class_type_info, vtable for __cxxabiv1::__si_class_type_info, vtable for __cxxabiv1::__vmi_class_type_info. The full output of the linking command is too long and is attached gzipped. The linking command is the following: > > Those symbols are from libc++abi, and it isn't on your link line.It depends on how you want to package libc++ whether you actually want to link to libc++abi. If you’re on a GNUish system, you almost certainly don’t, because you then won’t be able to combine libc++ and libstdc++ in the same binary. You want to add -lstdc++ to the link line (or, ideally, -lsupc++, if your distribution ships a separate libsupc++.so). On FreeBSD, we don’t link libc++ to any ABI library. Instead, both libc++.so and libstdc++.so are linker scripts that instruct anything that tries to link libc++ to link libc++.so.{version} and libcxxrt.so.{version}. David
Dmitry Golovin via llvm-dev
2017-Jun-06 20:41 UTC
[llvm-dev] libc++ failed to link against musl
Hi David, 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. Regards, Dmitry 06.06.2017, 20:40, "David Chisnall" <david.chisnall at cl.cam.ac.uk>:> On 5 Jun 2017, at 15:17, Jonathan Roelofs via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> On 6/5/17 5:17 AM, Dmitry Golovin via llvm-dev wrote: >>> I'm trying to build LLVM, Clang, LLD, compiler-rt, libc++, libc++abi and libunwind with musl-based toolchain. >>> >>> The configuration is the following: >>> >>> LIBCXX_HAS_MUSL_LIBC=ON >>> LIBCXX_HAS_GCC_S_LIB=OFF >>> CLANG_DEFAULT_CXX_STDLIB=libc++ >>> CLANG_DEFAULT_LINKER=lld >>> CLANG_DEFAULT_RTLIB=compiler-rt >>> LLVM_DEFAULT_TARGET_TRIPLE=x86_64-pc-linux-musl >>> LLVM_TARGET_ARCH=x86_64 >>> LLVM_TARGETS_TO_BUILD=X86 >>> >>> When linking libc++.so there are a lot of undefined references to __cxa_allocate_exception, __cxa_begin_catch, __cxa_end_catch, __cxa_free_exception, __cxa_guard_abort, __cxa_guard_acquire, __cxa_guard_release, __cxa_pure_virtual, __cxa_rethrow, __cxa_throw, __gxx_personality_v0, _Unwind_Resume, vtable for __cxxabiv1::__class_type_info, vtable for __cxxabiv1::__si_class_type_info, vtable for __cxxabiv1::__vmi_class_type_info. The full output of the linking command is too long and is attached gzipped. The linking command is the following: >> >> Those symbols are from libc++abi, and it isn't on your link line. > > It depends on how you want to package libc++ whether you actually want to link to libc++abi. If you’re on a GNUish system, you almost certainly don’t, because you then won’t be able to combine libc++ and libstdc++ in the same binary. You want to add -lstdc++ to the link line (or, ideally, -lsupc++, if your distribution ships a separate libsupc++.so). > > On FreeBSD, we don’t link libc++ to any ABI library. Instead, both libc++.so and libstdc++.so are linker scripts that instruct anything that tries to link libc++ to link libc++.so.{version} and libcxxrt.so.{version}. > > David
Dimitry Andric via llvm-dev
2017-Jun-06 21:59 UTC
[llvm-dev] libc++ failed to link against musl
On 6 Jun 2017, at 19:40, David Chisnall via llvm-dev <llvm-dev at lists.llvm.org> wrote:> > On 5 Jun 2017, at 15:17, Jonathan Roelofs via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> On 6/5/17 5:17 AM, Dmitry Golovin via llvm-dev wrote: >>> I'm trying to build LLVM, Clang, LLD, compiler-rt, libc++, libc++abi and libunwind with musl-based toolchain. >>> >>> The configuration is the following: >>> >>> LIBCXX_HAS_MUSL_LIBC=ON >>> LIBCXX_HAS_GCC_S_LIB=OFF >>> CLANG_DEFAULT_CXX_STDLIB=libc++ >>> CLANG_DEFAULT_LINKER=lld >>> CLANG_DEFAULT_RTLIB=compiler-rt >>> LLVM_DEFAULT_TARGET_TRIPLE=x86_64-pc-linux-musl >>> LLVM_TARGET_ARCH=x86_64 >>> LLVM_TARGETS_TO_BUILD=X86 >>> >>> When linking libc++.so there are a lot of undefined references to __cxa_allocate_exception, __cxa_begin_catch, __cxa_end_catch, __cxa_free_exception, __cxa_guard_abort, __cxa_guard_acquire, __cxa_guard_release, __cxa_pure_virtual, __cxa_rethrow, __cxa_throw, __gxx_personality_v0, _Unwind_Resume, vtable for __cxxabiv1::__class_type_info, vtable for __cxxabiv1::__si_class_type_info, vtable for __cxxabiv1::__vmi_class_type_info. The full output of the linking command is too long and is attached gzipped. The linking command is the following: >> >> Those symbols are from libc++abi, and it isn't on your link line. > > It depends on how you want to package libc++ whether you actually want to link to libc++abi. If you’re on a GNUish system, you almost certainly don’t, because you then won’t be able to combine libc++ and libstdc++ in the same binary. You want to add -lstdc++ to the link line (or, ideally, -lsupc++, if your distribution ships a separate libsupc++.so). > > On FreeBSD, we don’t link libc++ to any ABI library. Instead, both libc++.so and libstdc++.so are linker scripts that instruct anything that tries to link libc++ to link libc++.so.{version} and libcxxrt.so.{version}.Note that this is not 100% true, our static libc++.a contains objects from libcxxrt. But this was unavoidable, at least not if you didn't want to inconvenience users. -Dimitry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: Message signed with OpenPGP URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170606/c41d28cd/attachment.sig>
David Chisnall via llvm-dev
2017-Jun-07 09:14 UTC
[llvm-dev] libc++ failed to link against musl
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