Re: make buildworld puts legacy tools into the /usr/obj/... tree
Date: Sun, 06 Aug 2023 16:05:38 UTC
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. matthias -- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub