From nobody Sun Aug 06 16:12:03 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RJkx66dJ9z4TxnR for ; Sun, 6 Aug 2023 16:12:10 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RJkx61JrKz3YdJ for ; Sun, 6 Aug 2023 16:12:10 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-52164adea19so4809478a12.1 for ; Sun, 06 Aug 2023 09:12:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20221208.gappssmtp.com; s=20221208; t=1691338328; x=1691943128; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=RgxzU+sv+uSPNZ3w7eSN8sbDdkGOjRexy8XMEISVaso=; b=BYsqbJPswqTETOuDIC8WGcaucoOhQAGxdRW+ntH0AFWZM7lkdWgdpTNt3daWhM1eoO rs45pSQ0/eby+LeIOSnPsHGNiY3zbFlLdxNOsesQsFbUkFgjpzd9fm6DFDbTBvaKPgfG JmPuwj5pAcqoSJ9+8dRcLTgmLLHzo8AwI4nQgcsuAtoQXp4vD6iyIGXKQ59sb9R3PK9R kFoieAh+6so8Hsbiyba2rcL6K9fADivqcKqvJZDOhLnd6xOtmRphjbMMluX2SaZSefQ4 SN4vj/05tEuVYygX3es7A/xBprx3kbeutGmrb2JcwcOBHcMAWiqPKr8ra2CO6DgU2Z5F XCKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691338328; x=1691943128; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=RgxzU+sv+uSPNZ3w7eSN8sbDdkGOjRexy8XMEISVaso=; b=cOwJWH2yPPrWW64D5/Sgiq0MiluE9+0qrnzkPYcNQ9yU8eb+V5mAHeQHtx8qAH3727 9Pxz+qPLN6wUR0Z0uFTjXXnWYrTZG/pu/rHFst0ruTP2+D5/AYNM+SQqu0pqqBcEhN9o IR+Yrz8TTnKfhTDCi3h8sLcGH/rv2rcvaCr9Vo1/mPfQlA4kduIXQ+IBT8N1b2J/SeU3 76ltm0jKY1StpzLzFmAqfEoIENa2kxFjXjvQiIilA4CmnOMY77OaTwjLIA/jPGLx03Te hnJbK7HRTlEZ1WrrtWiE39uvjvfVWgGPxkbsY21WaN5I6ofzO4laAuu+2SJcu9X8e5uV 33KA== X-Gm-Message-State: AOJu0YwUQNcil/FiFQMQazWrJ3NdDft6L8poko2hYaP+4yOSo6aL0qpj Urvev1mxG9X8tFMCZBxczupOlEotbOC67cyTJ4oBng== X-Google-Smtp-Source: AGHT+IEs1QcBaboJlwDQ3BogFKx1aGBVQmCaKlTSmg4D5IGi2jYyuDlhRKItIxlzPpiXkKwOF5PP9RuhApRmQj7G7xs= X-Received: by 2002:a50:ec95:0:b0:523:290c:3f78 with SMTP id e21-20020a50ec95000000b00523290c3f78mr3655300edr.14.1691338327879; Sun, 06 Aug 2023 09:12:07 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Sun, 6 Aug 2023 10:12:03 -0600 Message-ID: Subject: Re: make buildworld puts legacy tools into the /usr/obj/... tree To: Matthias Apitz , Warner Losh , freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="0000000000003a8e58060243644f" X-Rspamd-Queue-Id: 4RJkx61JrKz3YdJ X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] --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 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 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


=
On Sun, Aug 6, 2023 at 10:05=E2=80=AF= AM Matthias Apitz <guru@unixarea.de<= /a>> wrote:
E= l d=C3=ADa domingo, agosto 06, 2023 a las 09:58:32a. m. -0600, Warner Losh = 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 = wanted
> > 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 buildw= orld' 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=C2=A0 1 root wheel=C2=A0 =C2=A013304 Nov 30=C2=A0 2020= [
> > lrwxr-xr-x=C2=A0 1 root wheel=C2=A0 =C2=A0 =C2=A0 54 Aug=C2=A0 5 = 13:05 apropos ->
> > /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin/mandoc
> > -rwxr-xr-x=C2=A0 1 root wheel 1008512 Aug=C2=A0 5 13:05 asn1_comp= ile
> > -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
> > -r-xr-xr-x=C2=A0 1 root wheel=C2=A0 195712 Nov 30=C2=A0 2020 bmak= e
> > -r-xr-xr-x=C2=A0 1 root wheel=C2=A0 =C2=A033848 Nov 30=C2=A0 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 act= ual
> > system, for example
> >
> > # ldd /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin/tzsetup
> > /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin/tzsetup:
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0libdialog.so.8 =3D> not found= (0)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0libncursesw.so.9 =3D> /lib/li= bncursesw.so.9 (0xf283d7b4000)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0libc.so.7 =3D> /lib/libc.so.7= (0xf283e729000)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0libtinfow.so.9 =3D> /lib/libt= infow.so.9 (0xf283c93d000)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[vdso] (0xf283c4a4000)
> >
> > # which tzsetup
> > /usr/sbin/tzsetup
> > # ldd /usr/sbin/tzsetup
> > /usr/sbin/tzsetup:
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0libprivatebsddialog.so.0 =3D>= /usr/lib/libprivatebsddialog.so.0
> > (0x1797fe45c000)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0libc.so.7 =3D> /lib/libc.so.7= (0x1797fec89000)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0libncursesw.so.9 =3D> /lib/li= bncursesw.so.9 (0x1798011df000)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0libtinfow.so.9 =3D> /lib/libt= infow.so.9 (0x17980043d000)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0libformw.so.6 =3D> /usr/lib/l= ibformw.so.6 (0x17980164c000)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[vdso] (0x1797fe2d9000)
> >
> > Why is this with the tools in /usr/obj/usr/src/amd64.amd64/tmp/le= gacy/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 leg= acy
> 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.

S= o what's the vintage of the host you are building with? And what source= s are
you building...

Also of note: we s= witched to no-clean builds by default which is way faster, but
al= so exposes issues like this...

Warner
--0000000000003a8e58060243644f--