figure out how to statically link clang itself

[nickdesaulniers]

As part of putting a build of clang up on kernel.org, statically linking all dependencies would simplify distribution for the various linux distros (I suspect). I don't know how to do this today in LLVM's cmake; maybe we need to add some things to upstream LLVM to do so.

[MaskRay]

Regarding linking statically, I know that linking against libz.a has a CMake issue (https://lists.llvm.org/pipermail/llvm-dev/2021-May/150505.html). We may also want to use -DLLDB_ENABLE_LIBXML2=off and disable libpython to reduce some complexity (libxml2 and libpython are only used by lldb).

[ojeda]

When I looked into it briefly for Rust for Linux, with the same idea (uploading it to kernel.org), it was indeed clear it was either not possible, not supported, or if it was both, not clear how to do it.

But I agree, having a static build up there would be great.

[sylvestre]

I can give it a try at some point!

[nickdesaulniers]

@serge-sans-paille did I understand correctly in
https://lore.kernel.org/lkml/20210501195750.GA1480516@sguelton.remote.csb/
that you (or @tstellar ) are able to fully statically link clang?

[serge-sans-paille]

no, not fully as hinted by this thread. Let me give it a try.

[serge-sans-paille]

@nickdesaulniers I reached that point:

ldd ./bin/clang
        linux-vdso.so.1 (0x00007ffe0c3ae000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f80dbb64000)
        librt.so.1 => /lib64/librt.so.1 (0x00007f80dbb59000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f80dbb52000)
        libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f80db959000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f80db813000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f80db7f9000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f80db62e000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f80dbbc0000)

[ojeda]

I would love to have the recipe documented and supported by Clang, ideally with a configuration option...

Perhaps I am asking too much :)

[MaskRay]

For performance, a statically linked clang is no faster than a -fvisibility-inlines-hidden + -Bsymbolic-functions + -fno-semantic-interposition clang. We will soon switch to -fvisibility-inlines-hidden + -Bsymbolic-functions + -fno-semantic-interposition. See more on https://maskray.me/blog/2021-05-16-elf-interposition-and-bsymbolic

If statically linking requires some non-trivial changes to the llvm-project build system, I will object to that.

[ojeda]

For performance, a statically linked clang is no faster

That is not the only reason to have statically linked binaries.

If statically linking requires some non-trivial changes to the llvm-project build system, I will object to that.

It is clear users want it, though.

[serge-sans-paille]

@ojeda : simple enough: from your build dir (obviously you need to adapt your path)

$ cmake3 ../llvm -DLLVM_ENABLE_PROJECTS=clang -DTERMINFO_LIB=/opt/notnfs/sergesanspaille/install/lib/libncurses.a -DZLIB_LIBRARY_RELEASE=/opt/notnfs/sergesanspaille/install/lib/libz.a
[...]
$ make -j50 clang
[...]
$ ldd ./bin/clang
        linux-vdso.so.1 (0x00007fff4b3ca000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fe53549d000)
        librt.so.1 => /lib64/librt.so.1 (0x00007fe535492000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007fe53548b000)
        libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fe535292000)
        libm.so.6 => /lib64/libm.so.6 (0x00007fe53514c000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fe535132000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fe534f67000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fe5354f9000)

@MaskRay so no change to the configuration, just some usage of hidden cmake variables :-)

[ojeda]

@serge-sans-paille Thanks! That is helpful. I meant officially, in any case, i.e. having static builds supported by LLVM :)

[nickdesaulniers]

@serge-sans-paille that's closer, but I'm looking for a binary of clang that produces no output from ldd; ie. fully statically linked.

@MaskRay less so concerned with performance than being able to distribute a binary that works on various distributions without any concerns for depencencies (if possible).

I wonder if llvm-bazel can produce such an image? Looking at
https://github.com/google/llvm-bazel/blob/8bd5137faea24d1fc7215ace94924ff8eedad324/llvm-bazel/llvm-project-overlay/clang/BUILD.bazel#L1863-L1912, I don't see linkshared used.

EDIT: looks like the llvm-bazel scripts don't produce a statically linked clang binary. :(

[serge-sans-paille]

@nickdesaulniers I can't say for bazel, but the following works like a charm for me:

> cmake3 ../llvm -DLLVM_ENABLE_PROJECTS=clang -DCMAKE_EXE_LINKER_FLAGS=-static -DTERMINFO_LIB=/opt/notnfs/sergesanspaille/install/lib/libncurses.a -DZLIB_LIBRARY_RELEASE=/opt/notnfs/sergesanspaille/install/lib/libz.a
[...]
> make -j50 clang
[...]
> ldd ./bin/clang
        not a dynamic executable
> printf '#include <stdio.h>\nint main() { puts("yes"); return 0;}' | ./bin/clang -xc -  && ./a.out
yes