> > > Let me guess. You use 'make' in sys/i386/build/YOUR_KERNEL ? > > > Then you need to use 'LD=ld.ldd make'. The proper way of > > > 'make buildkernel' from top-level src handles it automatically. > > > > > If you back up in the thread you would also see the output > > is the same for cd /usr/src; make buildkernel conf=CUSTOM > > "make buildworld" or "make kernel-toolchain" needs to be run first.Are you really rally expecting a user to rebuild the world that he just installed that should be exactly the same world he gets build (reproduceable builds and all??). But in your other mail you said the proper toolchain is included, so this is not really true?> Also, there's a typo in kib's command - it should be LD=ld.lld (two > 'l's, not two 'd's). > > There's more information about this issue (when it applied to amd64) > at https://lists.freebsd.org/pipermail/freebsd-arch/2018-May/018967.html.Yes I remeber the issue but we shipped a release with the issue in it? An issue that was hit 7 months before the release? Really? Isn't this just a mater of fixing the toplevel make at /usr/src for target buildkernel to include the LD=ld.lld or fixing the kernel Makefile likewise? -- Rod Grimes rgrimes at freebsd.org
> > > > Let me guess. You use 'make' in sys/i386/build/YOUR_KERNEL ? > > > > Then you need to use 'LD=ld.ldd make'. The proper way of > > > > 'make buildkernel' from top-level src handles it automatically. > > > > > > > If you back up in the thread you would also see the output > > > is the same for cd /usr/src; make buildkernel conf=CUSTOM > > > > "make buildworld" or "make kernel-toolchain" needs to be run first. > > Are you really rally expecting a user to rebuild the world that > he just installed that should be exactly the same world he gets > build (reproduceable builds and all??). > > But in your other mail you said the proper toolchain is included, > so this is not really true? > > > Also, there's a typo in kib's command - it should be LD=ld.lld (two > > 'l's, not two 'd's). > > > > There's more information about this issue (when it applied to amd64) > > at https://lists.freebsd.org/pipermail/freebsd-arch/2018-May/018967.html. > > Yes I remeber the issue but we shipped a release with the issue in it? > An issue that was hit 7 months before the release? > Really? > > Isn't this just a mater of fixing the toplevel make at > /usr/src for target buildkernel to include the LD=ld.lld or > fixing the kernel Makefile likewise?I have confirmed that cd /usr/src; LD=ld.lld make buildkernel config=GENERIC does resolve this issue, so can we add LD=ld.lld to the buildkernel target and fix the kernel Makefile on i386 to have this set? (On RELENG/12.0 branch).> Rod Grimes rgrimes at freebsd.org-- Rod Grimes rgrimes at freebsd.org
On Thu, 28 Feb 2019 at 08:26, Rodney W. Grimes <freebsd at pdx.rh.cn85.dnsmgr.net> wrote:> > Are you really rally expecting a user to rebuild the world that > he just installed that should be exactly the same world he gets > build (reproduceable builds and all??).I'm expecting that a user will either follow the directions in the handbook (or use the LD=ld.lld override). A user that rebuilds the world they just installed will indeed get the same world.> But in your other mail you said the proper toolchain is included, > so this is not really true?> Yes I remeber the issue but we shipped a release with the issue in it? > An issue that was hit 7 months before the release? > Really?Yes, unfortunately re and portmgr asked me not to change this for the release.> Isn't this just a mater of fixing the toplevel make at > /usr/src for target buildkernel to include the LD=ld.lld or > fixing the kernel Makefile likewise?Possibly, but we don't want to break things if the user provides their own setting for LD=. I had a brief look at it when this issue existed on amd64 but there was no trivial fix.