Date: Sun, 6 Aug 2023 10:12:03 -0600 From: Warner Losh <imp@bsdimp.com> To: Matthias Apitz <guru@unixarea.de>, Warner Losh <imp@bsdimp.com>, freebsd-current@freebsd.org Subject: Re: make buildworld puts legacy tools into the /usr/obj/... tree Message-ID: <CANCZdfpackhr99ctRDz6WnJ32HE%2Bg=AhoSn=eDSPpdyW%2BBkJUA@mail.gmail.com> In-Reply-To: <ZM/E0gkUG9cIcpyg@c720-r368166> References: <ZM%2Bm3mTsXQkZeyv7@c720-r368166> <CANCZdfrCE-pybJfrzUANg14Tzn65o_eGegBrQxFb9giUbB9w1A@mail.gmail.com> <ZM/E0gkUG9cIcpyg@c720-r368166>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] On Sun, Aug 6, 2023 at 10:05 AM Matthias Apitz <guru@unixarea.de> wrote: > El día domingo, agosto 06, 2023 a las 09:58:32a. m. -0600, Warner Losh > escribió: > > > On Sun, Aug 6, 2023 at 7:58 AM Matthias Apitz <guru@unixarea.de> wrote: > > > > > > > > I did, based of a git clone of head, a clean compile of world and > kernel > > > with > > > > > > # cd /usr > > > # rm -rf obj > > > # mkdir obj > > > # cd src > > > # make -j8 buildworld > > > # make -j8 buildkernel > > > ... > > > I installed the result and the system runs fine. For some test I wanted > > > to do another installation to some DESTDIR with > > > > > > # make installworld DESTDIR=/home/... > > > > > > This failed with: > > > > > > --- installworld --- > > > mkdir -p /tmp/install.j76anzU56j > > > > > > ... > > > Required library libdialog.so.8 not found. > > > *** [installworld] Error code 1 > > > > > > make[1]: stopped in /usr/src > > > > > > Investigating the problem it turned out that the 'make buildworld' puts > > > a lot of legacy binaries in to some directory: > > > > > > # ls -l /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin > > > total 36976 > > > -r-xr-xr-x 1 root wheel 13304 Nov 30 2020 [ > > > lrwxr-xr-x 1 root wheel 54 Aug 5 13:05 apropos -> > > > /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin/mandoc > > > -rwxr-xr-x 1 root wheel 1008512 Aug 5 13:05 asn1_compile > > > -r-xr-xr-x 1 root wheel 217504 Nov 30 2020 awk > > > -r-xr-xr-x 1 root wheel 9576 Nov 30 2020 basename > > > -r-xr-xr-x 1 root wheel 195712 Nov 30 2020 bmake > > > -r-xr-xr-x 1 root wheel 33848 Nov 30 2020 bunzip2 > > > ... > > > They are all from the system before updating it (from Nov 30 2020) and > > > of course are missing shared libs when they get called in the actual > > > system, for example > > > > > > # ldd /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin/tzsetup > > > /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin/tzsetup: > > > libdialog.so.8 => not found (0) > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > libncursesw.so.9 => /lib/libncursesw.so.9 (0xf283d7b4000) > > > libc.so.7 => /lib/libc.so.7 (0xf283e729000) > > > libtinfow.so.9 => /lib/libtinfow.so.9 (0xf283c93d000) > > > [vdso] (0xf283c4a4000) > > > > > > # which tzsetup > > > /usr/sbin/tzsetup > > > # ldd /usr/sbin/tzsetup > > > /usr/sbin/tzsetup: > > > libprivatebsddialog.so.0 => /usr/lib/libprivatebsddialog.so.0 > > > (0x1797fe45c000) > > > libc.so.7 => /lib/libc.so.7 (0x1797fec89000) > > > libncursesw.so.9 => /lib/libncursesw.so.9 (0x1798011df000) > > > libtinfow.so.9 => /lib/libtinfow.so.9 (0x17980043d000) > > > libformw.so.6 => /usr/lib/libformw.so.6 (0x17980164c000) > > > [vdso] (0x1797fe2d9000) > > > > > > Why is this with the tools in > /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin ? > > > Or what I have done wrong or overlooked? > > > > > > > So, the build process builds tools that are used to make and install > > FreeBSD. > > That's what legacy is about: providing a compatible way to do all this. > We > > setup env vars, etc, so that these tools pull their libraries from legacy > > as well > > so that we have a consistent set of binaries to run on while the rest of > > the world > > is being replaced. I'm surprised to see this failing, since it's what > > nanobsd does > > all the time, and I build new systems with nanobsd every week based on > > recent > > current trees. > > > > Is there a libdalog.so.8 in your tmp/legacy tree at all? > > No, there is not: > > root@jet:~ # find /usr/obj.broken -name libdalog.so.8 > root@jet:~ # > > The problem, for sure, is not when you build every day, but in my case > the last build (and the system used for building) was 2 years old. And > note: > I started with an empty new /usr/obj. > So what's the vintage of the host you are building with? And what sources are you building... Also of note: we switched to no-clean builds by default which is way faster, but also exposes issues like this... Warner [-- Attachment #2 --] <div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Aug 6, 2023 at 10:05 AM Matthias Apitz <<a href="mailto:guru@unixarea.de">guru@unixarea.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">El día domingo, agosto 06, 2023 a las 09:58:32a. m. -0600, Warner Losh escribió:<br> <br> > On Sun, Aug 6, 2023 at 7:58 AM Matthias Apitz <<a href="mailto:guru@unixarea.de" target="_blank">guru@unixarea.de</a>> wrote:<br> > <br> > ><br> > > I did, based of a git clone of head, a clean compile of world and kernel<br> > > with<br> > ><br> > > # cd /usr<br> > > # rm -rf obj<br> > > # mkdir obj<br> > > # cd src<br> > > # make -j8 buildworld<br> > > # make -j8 buildkernel<br> > > ...<br> > > I installed the result and the system runs fine. For some test I wanted<br> > > to do another installation to some DESTDIR with<br> > ><br> > > # make installworld DESTDIR=/home/...<br> > ><br> > > This failed with:<br> > ><br> > > --- installworld ---<br> > > mkdir -p /tmp/install.j76anzU56j<br> > ><br> > > ...<br> > > Required library libdialog.so.8 not found.<br> > > *** [installworld] Error code 1<br> > ><br> > > make[1]: stopped in /usr/src<br> > ><br> > > Investigating the problem it turned out that the 'make buildworld' puts<br> > > a lot of legacy binaries in to some directory:<br> > ><br> > > # ls -l /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin<br> > > total 36976<br> > > -r-xr-xr-x 1 root wheel 13304 Nov 30 2020 [<br> > > lrwxr-xr-x 1 root wheel 54 Aug 5 13:05 apropos -><br> > > /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin/mandoc<br> > > -rwxr-xr-x 1 root wheel 1008512 Aug 5 13:05 asn1_compile<br> > > -r-xr-xr-x 1 root wheel 217504 Nov 30 2020 awk<br> > > -r-xr-xr-x 1 root wheel 9576 Nov 30 2020 basename<br> > > -r-xr-xr-x 1 root wheel 195712 Nov 30 2020 bmake<br> > > -r-xr-xr-x 1 root wheel 33848 Nov 30 2020 bunzip2<br> > > ...<br> > > They are all from the system before updating it (from Nov 30 2020) and<br> > > of course are missing shared libs when they get called in the actual<br> > > system, for example<br> > ><br> > > # ldd /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin/tzsetup<br> > > /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin/tzsetup:<br> > > libdialog.so.8 => not found (0)<br> > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<br> > > libncursesw.so.9 => /lib/libncursesw.so.9 (0xf283d7b4000)<br> > > libc.so.7 => /lib/libc.so.7 (0xf283e729000)<br> > > libtinfow.so.9 => /lib/libtinfow.so.9 (0xf283c93d000)<br> > > [vdso] (0xf283c4a4000)<br> > ><br> > > # which tzsetup<br> > > /usr/sbin/tzsetup<br> > > # ldd /usr/sbin/tzsetup<br> > > /usr/sbin/tzsetup:<br> > > libprivatebsddialog.so.0 => /usr/lib/libprivatebsddialog.so.0<br> > > (0x1797fe45c000)<br> > > libc.so.7 => /lib/libc.so.7 (0x1797fec89000)<br> > > libncursesw.so.9 => /lib/libncursesw.so.9 (0x1798011df000)<br> > > libtinfow.so.9 => /lib/libtinfow.so.9 (0x17980043d000)<br> > > libformw.so.6 => /usr/lib/libformw.so.6 (0x17980164c000)<br> > > [vdso] (0x1797fe2d9000)<br> > ><br> > > Why is this with the tools in /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin ?<br> > > Or what I have done wrong or overlooked?<br> > ><br> > <br> > So, the build process builds tools that are used to make and install<br> > FreeBSD.<br> > That's what legacy is about: providing a compatible way to do all this. We<br> > setup env vars, etc, so that these tools pull their libraries from legacy<br> > as well<br> > so that we have a consistent set of binaries to run on while the rest of<br> > the world<br> > is being replaced. I'm surprised to see this failing, since it's what<br> > nanobsd does<br> > all the time, and I build new systems with nanobsd every week based on<br> > recent<br> > current trees.<br> > <br> > Is there a libdalog.so.8 in your tmp/legacy tree at all?<br> <br> No, there is not:<br> <br> root@jet:~ # find /usr/obj.broken -name libdalog.so.8<br> root@jet:~ # <br> <br> The problem, for sure, is not when you build every day, but in my case<br> the last build (and the system used for building) was 2 years old. And note:<br> I started with an empty new /usr/obj.<br></blockquote><div><br></div><div>So what's the vintage of the host you are building with? And what sources are</div><div>you building...</div><div><br></div><div>Also of note: we switched to no-clean builds by default which is way faster, but</div><div>also exposes issues like this...<br></div><div><br></div><div>Warner <br></div></div></div>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfpackhr99ctRDz6WnJ32HE%2Bg=AhoSn=eDSPpdyW%2BBkJUA>