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
--0000000000003a8e58060243644f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Aug 6, 2023 at 10:05=E2=80=AFAM Matthias Apitz <guru@unixarea.de> w= rote: > El d=C3=ADa domingo, agosto 06, 2023 a las 09:58:32a. m. -0600, Warner Lo= sh > escribi=C3=B3: > > > On Sun, Aug 6, 2023 at 7:58=E2=80=AFAM 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 want= ed > > > to do another installation to some DESTDIR with > > > > > > # make installworld DESTDIR=3D/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' pu= ts > > > 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) an= d > > > 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 =3D> not found (0) > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > libncursesw.so.9 =3D> /lib/libncursesw.so.9 (0xf283d7b4000) > > > libc.so.7 =3D> /lib/libc.so.7 (0xf283e729000) > > > libtinfow.so.9 =3D> /lib/libtinfow.so.9 (0xf283c93d000) > > > [vdso] (0xf283c4a4000) > > > > > > # which tzsetup > > > /usr/sbin/tzsetup > > > # ldd /usr/sbin/tzsetup > > > /usr/sbin/tzsetup: > > > libprivatebsddialog.so.0 =3D> /usr/lib/libprivatebsddialog.so= .0 > > > (0x1797fe45c000) > > > libc.so.7 =3D> /lib/libc.so.7 (0x1797fec89000) > > > libncursesw.so.9 =3D> /lib/libncursesw.so.9 (0x1798011df000) > > > libtinfow.so.9 =3D> /lib/libtinfow.so.9 (0x17980043d000) > > > libformw.so.6 =3D> /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 lega= cy > > as well > > so that we have a consistent set of binaries to run on while the rest o= f > > 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 --0000000000003a8e58060243644f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Sun, Aug 6, 2023 at 10:05=E2=80=AF= AM Matthias Apitz <<a href=3D"mailto:guru@unixarea.de">guru@unixarea.de<= /a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0= px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">E= l d=C3=ADa domingo, agosto 06, 2023 a las 09:58:32a. m. -0600, Warner Losh = escribi=C3=B3:<br> <br> > On Sun, Aug 6, 2023 at 7:58=E2=80=AFAM Matthias Apitz <<a href=3D"m= ailto:guru@unixarea.de" target=3D"_blank">guru@unixarea.de</a>> wrote:<b= r> > <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=3D/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 buildw= orld' 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=C2=A0 1 root wheel=C2=A0 =C2=A013304 Nov 30=C2=A0 2020= [<br> > > lrwxr-xr-x=C2=A0 1 root wheel=C2=A0 =C2=A0 =C2=A0 54 Aug=C2=A0 5 = 13:05 apropos -><br> > > /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin/mandoc<br> > > -rwxr-xr-x=C2=A0 1 root wheel 1008512 Aug=C2=A0 5 13:05 asn1_comp= ile<br> > > -r-xr-xr-x=C2=A0 1 root wheel=C2=A0 217504 Nov 30=C2=A0 2020 awk<= br> > > -r-xr-xr-x=C2=A0 1 root wheel=C2=A0 =C2=A0 9576 Nov 30=C2=A0 2020= basename<br> > > -r-xr-xr-x=C2=A0 1 root wheel=C2=A0 195712 Nov 30=C2=A0 2020 bmak= e<br> > > -r-xr-xr-x=C2=A0 1 root wheel=C2=A0 =C2=A033848 Nov 30=C2=A0 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 act= ual<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> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0libdialog.so.8 =3D> not found= (0)<br> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<b= r> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0libncursesw.so.9 =3D> /lib/li= bncursesw.so.9 (0xf283d7b4000)<br> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0libc.so.7 =3D> /lib/libc.so.7= (0xf283e729000)<br> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0libtinfow.so.9 =3D> /lib/libt= infow.so.9 (0xf283c93d000)<br> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[vdso] (0xf283c4a4000)<br> > ><br> > > # which tzsetup<br> > > /usr/sbin/tzsetup<br> > > # ldd /usr/sbin/tzsetup<br> > > /usr/sbin/tzsetup:<br> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0libprivatebsddialog.so.0 =3D>= /usr/lib/libprivatebsddialog.so.0<br> > > (0x1797fe45c000)<br> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0libc.so.7 =3D> /lib/libc.so.7= (0x1797fec89000)<br> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0libncursesw.so.9 =3D> /lib/li= bncursesw.so.9 (0x1798011df000)<br> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0libtinfow.so.9 =3D> /lib/libt= infow.so.9 (0x17980043d000)<br> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0libformw.so.6 =3D> /usr/lib/l= ibformw.so.6 (0x17980164c000)<br> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[vdso] (0x1797fe2d9000)<br> > ><br> > > Why is this with the tools in /usr/obj/usr/src/amd64.amd64/tmp/le= gacy/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<b= r> > 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 leg= acy<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>S= o what's the vintage of the host you are building with? And what source= s are</div><div>you building...</div><div><br></div><div>Also of note: we s= witched to no-clean builds by default which is way faster, but</div><div>al= so exposes issues like this...<br></div><div><br></div><div>Warner <br></di= v></div></div> --0000000000003a8e58060243644f--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfpackhr99ctRDz6WnJ32HE%2Bg=AhoSn=eDSPpdyW%2BBkJUA>