llvm dev - Jun 2017 - 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

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.

Regards,
Dmitry

On 7 Jun 2017, at 10:49, Dmitry Golovin <dima at golovin.in>
wrote:
> 
> 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.
Correct, though on FreeBSD we still install the libunwind / compiler-rt
combination as libgcc_s.so, because then we don’t break existing binaries or
compilers.
> 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.
You might find it informative to look at how the FreeBSD toolchain works.

David