llvm dev - Apr 2017 - Statically linking against libc++

While considering statically linking against libc++ (and
other runtime libraries from LLVM), I rebuilt LLVM 4.0
with -DBUILD_SHARED_LIBS=OFF.

There are still some .so's in llvm/lib, and only one
of them seems to exist exclusively as a DSO (libLTO).
There's also livLLVMLTO.a, but I doubt LTO is used
after linking a binary so this just looks odd to an
uninformed LLVM outside and not insufficient or anything.

My question is two-fold:

1. when building a C++ program with clang, maybe making use
of clang-musl to avoid glibc as well, how do I statically
link libc++ and get a C++ program that runs on any Linux
kernel, allowing easy distribution of a single binary?

2. should the following .so's be built with -DBUILD_SHARED_LIBS=OFF?

$ ls *.so
BugpointPasses.so
LLVMHello.so
LLVMPolly.so
LLVMgold.so
libLTO.so
libc++.so
libc++abi.so
libclang.so
libgomp.so
libiomp5.so
liblldb.so
libomp.so

On 9 Apr 2017, at 18:05, Carsten Mattner via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> While considering statically linking against libc++ (and
> other runtime libraries from LLVM), I rebuilt LLVM 4.0
> with -DBUILD_SHARED_LIBS=OFF.
> 
> There are still some .so's in llvm/lib, and only one
> of them seems to exist exclusively as a DSO (libLTO).
> There's also livLLVMLTO.a, but I doubt LTO is used
> after linking a binary so this just looks odd to an
> uninformed LLVM outside and not insufficient or anything.
> 
> My question is two-fold:
> 
> 1. when building a C++ program with clang, maybe making use
> of clang-musl to avoid glibc as well, how do I statically
> link libc++ and get a C++ program that runs on any Linux
> kernel, allowing easy distribution of a single binary?
If you want to link just libc++ statically, you can use:

  -Wl,-Bstatic -lc++ -Wl,-Bdynamic

in your link flags.  Otherwise, just use -static.

> 2. should the following .so's be built with -DBUILD_SHARED_LIBS=OFF?
> 
> $ ls *.so
> BugpointPasses.so
> LLVMHello.so
> LLVMPolly.so
> LLVMgold.so
> libLTO.so
> libc++.so
> libc++abi.so
> libclang.so
> libgomp.so
> libiomp5.so
> liblldb.so
> libomp.so
Indeed, those should probably be cleaned up.  On the other hand, some
libraries do not really make sense as static ones, so those could be
completely disabled.

-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/20170409/4d8b907c/attachment.sig>

On Sun, Apr 9, 2017 at 4:49 PM, Dimitry Andric wrote:
> Otherwise, just use -static.
So obvious and easy. I'm so used (stockholm syndrome?)
to not being able to link Linux (aka glibc+libstd++)
statically that I didn't expect this.

I'm surprised this clang++ foo.cc -static -o foo
produced a foo that doesn't required glibc. I would
have thought that this would have failed to link
without involving musl, which I don't know how to
include since musl outside a musl chroot/distro
only has musl-clang for building C code without
the C++ frontend, where one probably needs to
explicitly add -lc++.

foo.cc wasn't tiny either, it includes fcntl.h,
sys/*.h, etc., in addition to the C++ standard
lib headers.

I'm on Arch Linux where there isn't any .a like
you would get on Gentoo or Debian's -dev packages,
so I wonder how this linked statically without me
telling it to use musl libc for the C symbols.
Do you know why?

> On Apr 9, 2017, at 9:05 AM, Carsten Mattner via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> While considering statically linking against libc++ (and
> other runtime libraries from LLVM), I rebuilt LLVM 4.0
> with -DBUILD_SHARED_LIBS=OFF.
What you build with clang and how clang is built aren’t related at all.
You can build LLVM as a set of dynamic libraries, and still use clang to
generate a statically linked binary.

> 
> There are still some .so's in llvm/lib, and only one
> of them seems to exist exclusively as a DSO (libLTO).
> There's also livLLVMLTO.a, but I doubt LTO is used
> after linking a binary so this just looks odd to an
> uninformed LLVM outside and not insufficient or anything.
> 
> My question is two-fold:
> 
> 1. when building a C++ program with clang, maybe making use
> of clang-musl to avoid glibc as well, how do I statically
> link libc++ and get a C++ program that runs on any Linux
> kernel, allowing easy distribution of a single binary?
> 
> 2. should the following .so's be built with -DBUILD_SHARED_LIBS=OFF?
Yes, most of them are intended to stay .so.

Note that -DBUILD_SHARED_LIBS=OFF is not a special settings, this is the
default.

— 
Mehdi

> 
> $ ls *.so
> BugpointPasses.so
> LLVMHello.so
> LLVMPolly.so
> LLVMgold.so
> libLTO.so
> libc++.so
> libc++abi.so
> libclang.so
> libgomp.so
> libiomp5.so
> liblldb.so
> libomp.so
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

On Mon, Apr 10, 2017 at 4:59 AM, Mehdi Amini <mehdi.amini at apple.com>
wrote:
>
> What you build with clang and how clang is built aren’t
> related at all.
> You can build LLVM as a set of dynamic libraries, and
> still use clang to generate a statically linked binary.
Of course not and I can see how my message was ambiguous.

Since C++ code almost always needs a standard lib and
given past precedents on Linux with glibc/libgcc/libstdc++,
I asked myself if and how I can statically link libc++.
This is a little more important because libc++ - unlike
FreeBSD and macOS - is not necessarily on a system. Hence
my static linking question. Looking closer, Arch linux
has libc.a even though it doesn't install .a for packages
by default so glibc's C stdlib must have been used in
that clang++ -static foo.cc invocation.

This is good but since glibc may not link statically in
all scenarios, do you know how I could run clang++ on a glibc
Linux while delegating C stdlib to musl-libc? I mean,
-nostdlib or -nodefaultlib could be used but then stuff
gets hairy or too explicit quickly. I'm hoping -static
could be made to use libc++.a, musl libc.a and maybe
libunwind compiler-rt etc.

On Mon, Apr 10, 2017 at 4:59 AM, Mehdi Amini <mehdi.amini at apple.com>
wrote:
> Note that -DBUILD_SHARED_LIBS=OFF is not a special settings,
> this is the default.
Is there a so=NEVER setting?