Date: Sun, 6 Aug 2023 18:22:43 +0200 From: Michael Gmelin <grembo@freebsd.org> To: Warner Losh <imp@bsdimp.com> Cc: Matthias Apitz <guru@unixarea.de>, freebsd-current@freebsd.org Subject: Re: make buildworld puts legacy tools into the /usr/obj/... tree Message-ID: <C65E8236-C5ED-444C-99CD-1E89B4582841@freebsd.org> In-Reply-To: <CANCZdfpackhr99ctRDz6WnJ32HE%2Bg=AhoSn=eDSPpdyW%2BBkJUA@mail.gmail.com> References: <CANCZdfpackhr99ctRDz6WnJ32HE%2Bg=AhoSn=eDSPpdyW%2BBkJUA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"></div><div dir="ltr"><br></div><div dir="ltr"><br><div dir="ltr"></div><blockquote type="cite">On 6. Aug 2023, at 18:12, Warner Losh <imp@bsdimp.com> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><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...</div></div></div> </div></blockquote><br><div>Thanks, this is valuable information (starts adapting idempotent playbooks).</div><div><br></div><div>-m</div></body></html>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C65E8236-C5ED-444C-99CD-1E89B4582841>