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

[Dimitry Andric via llvm-dev]

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>