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

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?

Warner