Re: make buildworld puts legacy tools into the /usr/obj/... tree

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