Re: HEADS-UP: Linker issues building amd64 kernels with config & make

On 15 May 2018, at 00:58, Ed Maste <emaste_at_freebsd.org> wrote:
> 
> On 14 May 2018 at 18:05, Julian H. Stacey <jhs_at_berklix.com> wrote:
>> 
>> I guess this explains :
>> Date: Sun, 13 May 2018 20:26:38 +0200
>> Subject: cd /sys/amd64/compile/GENERIC;make cleandepend; make cleandepend
>>        .svn_revision 333575
>>        linking kernel.full
>>        iflib.o:(.rodata+0x178): undefined reference to `noop_attach'
>>        iflib.o:(.rodata+0x188): undefined reference to `iflib_pseudo_detach'
> 
> No, that's something else; I haven't seen that problem before.
> 
> Note that we've been using lld as the default bootstrap linker (i.e.,
> the linker used to link the world and kernel via 'make buildworld' and
> 'make buildkernel') since Jan 10 (r327783).
> 
>> PS Bloat factor > 20: 2M static V 40M dynamic,
> 
> Keep in mind that the in-tree ld.bfd was released over a decade ago,
> and has been obsolete for years now; a dynamically-linked contemporary
> ld.bfd 12MB. lld is much faster than any of them (more than 20x
> compared to in-tree ld.bfd on some operations) and all of the target
> architectures are supported by a single binary.

Not just that: since lld can do link time optimization (LTO), it also
contains large parts of LLVM, e.g. the backend of the compiler.

We could maybe save some space by putting all the LLVM stuff into a
separate dynamic library, and re-using that from both clang and lld, but
such a dynamic library has its own issues.  (Takes a long time and lots
of memory to link, and probably takes quite some time to dynamically
load at runtime too.)

-Dimitry