ld.lld should be built as a static binary just like cc unless WITH_SHARED_TOOLCHAIN is set.
I would rather get rid of the WITH_SHARED_TOOLCHAIN option, as it is rather nonsensical in this day and age. But indeed, it is now inconsistent. Ed, Kostik, do you think it is worth the trouble linking lld statically? Maybe we can flip the MK_SHARED_TOOLCHAIN default to "yes", while we are at it...
(In reply to Dimitry Andric from comment #1) I am all for linking the toolchain shared, and I would even support removing WITH_SHARED_TOOLCHAIN at all, after it is flipped.
I am not sure if base system lld supports LTO, but it definitely needs to be linked shared for this to work even theoretically. I suppose that the first obstacle is that we do not provide LTO linker plugin in base, but also in port.
LLD doesn't need plugins for LTO since it should link against all necessary llvm code. That might obviously change if someone implements a plugin to LTO GCC-generated code.
I agree that WITH_SHARED_TOOLCHAIN should be the default. But here one small reason I care about having statically linked pre-built toolchain binaries. I have a really slow Intel Atom machine, buildworld on this machine takes 10+ hours, and most of that time is spent building llvm/clang twice. To save the toolchain bootstrap time, nowadays I download base.txz from the release I'm upgrading to, extract /usr/bin/{cc,c++,cpp,ld} and /usr/lib/clang, then do a make buildworld WITHOUT_CROSS_COMPILER=1. It's a massive timesaver. Because the base toolchain binaries are static I can almost always run newer version on older systems. When I tried this going to 12.1 RC it didn't work because ld.lld depended on a libc symbol I didn't have in 11.
Agreed ld.lld should be consistent with the rest of the toolchain.
A commit references this bug: Author: dim Date: Wed Oct 16 17:11:18 UTC 2019 New revision: 353655 URL: https://svnweb.freebsd.org/changeset/base/353655 Log: Ensure lld respects the WITH/WITHOUT_SHARED_TOOLCHAIN option Traditionally, toolchain components such as cc, as, and ld have been built as static executables. The WITH_SHARED_TOOLCHAIN option from src.conf(5) is meant to link these as regular executables, e.g. using shared libraries. The build of ld.lld did not yet check this option. Fix the Makefile so it will do so now. Reported by: Mike Cui <cuicui@gmail.com> PR: 241257 MFC after: 3 days Changes: head/usr.bin/clang/lld/Makefile
(In reply to Mike Cui from comment #5) > Because the base toolchain binaries are static I can almost always run newer version on older systems. When I tried this going to 12.1 RC it didn't work because ld.lld depended on a libc symbol I didn't have in 11. I understand that it can be a time-saver, but in general, even a statically linked binary from a newer release (and certainly a major release) is not guaranteed to run on an older kernel, specifically because there may have been changes in syscalls. That said, compilers and linkers tend to use a relatively minor set of those, and also the ones that don't change behavior very often (e.g. reading/writing files, basic process management). So these are less likely to break. :)
On machines with many cores/threads, having cc/c++/ld statically linked is less efficient, wasting CPU, memory and I/O resources, specially when building things. Would LD_LIBRARY_PATH environment variable help when using an alternative sysroot?
A commit references this bug: Author: dim Date: Sat Oct 19 15:58:21 UTC 2019 New revision: 353765 URL: https://svnweb.freebsd.org/changeset/base/353765 Log: MFC r353655: Ensure lld respects the WITH/WITHOUT_SHARED_TOOLCHAIN option Traditionally, toolchain components such as cc, as, and ld have been built as static executables. The WITH_SHARED_TOOLCHAIN option from src.conf(5) is meant to link these as regular executables, e.g. using shared libraries. The build of ld.lld did not yet check this option. Fix the Makefile so it will do so now. Reported by: Mike Cui <cuicui@gmail.com> PR: 241257 Changes: _U stable/11/ stable/11/usr.bin/clang/lld/Makefile _U stable/12/ stable/12/usr.bin/clang/lld/Makefile