From nobody Mon Apr 24 21:05:16 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 4Q4yMc5NzDz47M8B for ; Mon, 24 Apr 2023 21:05:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x930.google.com (mail-ua1-x930.google.com [IPv6:2607:f8b0:4864:20::930]) (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 4Q4yMb165wz3nFy for ; Mon, 24 Apr 2023 21:05:31 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ua1-x930.google.com with SMTP id a1e0cc1a2514c-77858d8dcb5so21097003241.1 for ; Mon, 24 Apr 2023 14:05:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20221208.gappssmtp.com; s=20221208; t=1682370330; x=1684962330; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=+UGUkCPx6ChSPrMaNyHtE2UNs6d3QPbE7SaWjF02JAg=; b=yY4TxTI4EHWotsQbz9zRsxAoJR21r06bML4Xt+N057PlvegPLze7raG9JTQSwpzOI4 ITtZcpdXKslt612MlgZnH1pcdoul12GAYwcerYGcyZR+iBcfcJ5fvzXef2nyOgeLVy4u Xabf98RmD2/jNIMYzPq6rVUSRaxAMl5PBMarnQzOiLAZzsza6+y4OVMaG89VUqZQ32b7 lIbTqs6ZlFjeuJEsy9STymZOT8ZDA6mIQDV9ti8nq/M7kvD1BFRqB5y+Evf3N3QsDIPI BXDOh0OGKny068J6YOgbtPkViyP775IY+j2x96oW5gCV9owidHp4d/2tMQV0G2dNZml4 24iQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682370330; x=1684962330; h=cc: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=+UGUkCPx6ChSPrMaNyHtE2UNs6d3QPbE7SaWjF02JAg=; b=Qc2FNzqk08euYEXvVda+H7qUG7Fu2zK+D+12Utb+Umz68qJUq8+3egdCG0HwK9jvk9 CgbnWxk0MSrON2Ep4GyndP9mRWSGRS4z4bOIl+olcz7QwsSgBOQS0w2B2dIFdpTFzsah V2tDtXbK68CYpvApHajdzVMx6mn7VNyHMPkIE1VfPdWiT9a81+gnu3wd/688pmmzuODw 5upQrPh++Z2Zs5Tgz1GpQ1R5Jbg+vvYNWl03KpE7/P1e3oMFyMJRDP40hNHZuU8+OLuu h4E0un8MmKmRa6D/jsIYjZtD/bPGUkIiH5J/BjPCjQNzn5MK2q6/BIu5rGYqeaVFxQBx se7w== X-Gm-Message-State: AAQBX9eyoYMxwR8J9HccxuGHuQSp734L077ZVxatz17tPnMRE0pTSOdr 8gJHlvJUxbH+6vXNhHY3rfo707ZjhkFUq8zGczcKaA== X-Google-Smtp-Source: AKy350ZVDooxuJ0YtFMQ+uxgIvT4g6hYgOpSJADc3PD7vsMUAC9Qzuz9zsuOjzyEGMngkLkDi6vvFwq1xAM8kUuaIn0= X-Received: by 2002:a05:6122:179a:b0:443:7204:786e with SMTP id o26-20020a056122179a00b004437204786emr5827198vkf.0.1682370329757; Mon, 24 Apr 2023 14:05:29 -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: <5B26AB25-075F-4630-86C1-886E6082CDCF.ref@yahoo.com> <5B26AB25-075F-4630-86C1-886E6082CDCF@yahoo.com> <90353.1682307584@kaos.jnpr.net> In-Reply-To: From: Warner Losh Date: Mon, 24 Apr 2023 15:05:16 -0600 Message-ID: Subject: Re: /lib/libc.so.7 vs. __libc_start1@FBSD_1.7 in main [so: 14] recently ? To: Mark Millard Cc: "Simon J. Gerraty" , FreeBSD Toolchain , Current FreeBSD Content-Type: multipart/alternative; boundary="000000000000e2e31b05fa1b5d05" X-Rspamd-Queue-Id: 4Q4yMb165wz3nFy X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --000000000000e2e31b05fa1b5d05 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Apr 23, 2023 at 10:22=E2=80=AFPM Mark Millard w= rote: > [Warner answered my specific question separately. This is about > something else.] > > On Apr 23, 2023, at 20:57, Warner Losh wrote: > > > On Sun, Apr 23, 2023 at 9:40=E2=80=AFPM Simon J. Gerraty > wrote: > >> Mark Millard wrote: > >> > I will not get into why, but I executed a git built for 1400082 > >> > in a 1400081 world context and got what was to me a surprise, > >> > given that /lib/libc.so.7 is part of 13.2-RELEASE : > >> > > >> > ld-elf.so.1: /usr/local/bin/git: Undefined symbol > "__libc_start1@FBSD_1.7" > >> > >> This is a symptom of trying to run a prog built for target on a host > >> which is not the same. > >> > >> I hit this a lot recently while updating Makefile.depend files for > >> userland. > >> > >> There are a number of makefiles (eg for sh, csh, awk) which need to ru= n > >> a tool on the host to generate something. > >> When trying to build 14.0 on a 13.1 host each of those tools failed wi= th > >> the above issue until actually built for the host. > > > > Your path is messed up then. We always run (a copy of) the host's > binaries > > for these tools. > > For the kernel's vers.c generation, git is used but > does not get a build of its own under buildworld or > buildkernel as far as I know: not a bootstrap or > staged tool. > Correct. The host's git is assumed to always be good and always executing in a sane env. And you can just remove / take git out of the path if you hit problems here= . > > If you were running the 14 binaries on 13 as part of the > > build process, the path is messed up. I'm not surprised for dirdep > > since it doesn't do all the staging activities that buildworld. > > git use is not covered by buildworld or kernel-toolchain > staging activities as far as I know. > > Is git the only example of such for things used by buildworld > or buildkernel ? > buildkernel is the only place I know that git is used to get the tip of git branch for messages. I think that reproducible builds omit this. Warner > >> AFAIK the non-DIRDEPS_BUILD build does a separate pass through the tre= e > >> to do the target build-tools to build these things. > > > > Yes and no... We copy the host's tools when we can, and build a matched > set of > > binary and libraries when the host one isn't good enough. I think it's = a > path > > issue you are seeing... > > > > Also, "copy" isn't a physical copy because macos hates copied binaries > due to security concerns. > > > >> > >> The DIRDEPS_BUILD uses a pseudo MACHINE "host" to deal with such thing= s, > >> ideally those tools would be built in a subdirectory of sh, csh etc, s= o > >> that one can choose to build only that tool if desired - sometimes you > >> want to build the app (eg awk) for the host as well but usually not. > > > > Yea, buildworld deals with this by creating new binaries and installing > them in > > a special directory, which is somewhat similar (though we always build > > them rather than on demand like dirdep hopes to do). > > > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > > > --000000000000e2e31b05fa1b5d05 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Apr 23, 2023 at 10:22=E2=80= =AFPM Mark Millard <marklmi@yahoo.c= om> wrote:
imp@bsdimp.com> wrote:

> On Sun, Apr 23, 2023 at 9:40=E2=80=AFPM Simon J. Gerraty <sjg@juniper.net> wrote= :
>> Mark Millard <marklmi@yahoo.com> wrote:
>> > I will not get into why, but I executed a git built for 14000= 82
>> > in a 1400081 world context and got what was to me a surprise,=
>> > given that /lib/libc.so.7 is part of 13.2-RELEASE :
>> >
>> > ld-elf.so.1: /usr/local/bin/git: Undefined symbol "__lib= c_start1@FBSD_1.7"
>>
>> This is a symptom of trying to run a prog built for target on a ho= st
>> which is not the same.
>>
>> I hit this a lot recently while updating Makefile.depend files for=
>> userland.
>>
>> There are a number of makefiles (eg for sh, csh, awk) which need t= o run
>> a tool on the host to generate something.
>> When trying to build 14.0 on a 13.1 host each of those tools faile= d with
>> the above issue until actually built for the host.
>
> Your path is messed up then. We always run (a copy of) the host's = binaries
> for these tools.

For the kernel's vers.c generation, git is used but
does not get a build of its own under buildworld or
buildkernel as far as I know: not a bootstrap or
staged tool.

Correct. The host's gi= t is assumed to always be good and always executing in a sane env.
And you can just remove / take git out of the path if you hit problems he= re.
=C2=A0
> If you were running the 14 binaries on 13 as part of the
> build process, the path is messed up. I'm not surprised for dirdep=
> since it doesn't do all the staging activities that buildworld.
git use is not covered by buildworld or kernel-toolchain
staging activities as far as I know.

Is git the only example of such for things used by buildworld
or buildkernel ?

buildkernel is the onl= y place I know that git is used to get the tip of git branch for messages. = I think that reproducible builds omit this.

Warner=
=C2=A0
>> AFAIK the non-DIRDEPS_BUILD build does a separate pass through the= tree
>> to do the target build-tools to build these things.
>
> Yes and no... We copy the host's tools when we can, and build a ma= tched set of
> binary and libraries when the host one isn't good enough. I think = it's a path
> issue you are seeing...
>
> Also, "copy" isn't a physical copy because macos hates c= opied binaries due to security concerns.
>=C2=A0
>>
>> The DIRDEPS_BUILD uses a pseudo MACHINE "host" to deal w= ith such things,
>> ideally those tools would be built in a subdirectory of sh, csh et= c, so
>> that one can choose to build only that tool if desired - sometimes= you
>> want to build the app (eg awk) for the host as well but usually no= t.
>
> Yea, buildworld deals with this by creating new binaries and installin= g them in
> a special directory, which is somewhat similar (though we always build=
> them rather than on demand like dirdep hopes to do).


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


--000000000000e2e31b05fa1b5d05--