Date: Mon, 14 May 2018 18:58:25 -0400 From: Ed Maste <emaste@freebsd.org> To: "Julian H. Stacey" <jhs@berklix.com> Cc: current <current@freebsd.org> Subject: Re: HEADS-UP: Linker issues building amd64 kernels with config & make Message-ID: <CAPyFy2Ae0hXGZJTiiz8Q6NAWd1-7_j2UHFsm=20zJ3WJKL9fng@mail.gmail.com> In-Reply-To: <201805142205.w4EM5j5w010919@fire.js.berklix.net> References: <CAPyFy2CyLChddhe7ONpTiJHA3HBrXJ_DXFCbkPyYNA7AxnzeUA@mail.gmail.com> <201805142205.w4EM5j5w010919@fire.js.berklix.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 14 May 2018 at 18:05, Julian H. Stacey <jhs@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPyFy2Ae0hXGZJTiiz8Q6NAWd1-7_j2UHFsm=20zJ3WJKL9fng>