From nobody Mon Apr 24 03:57:06 2023 X-Original-To: freebsd-toolchain@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 4Q4WYF1S1gz46wLw for ; Mon, 24 Apr 2023 03:57:21 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) (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 4Q4WYC6qfgz3sxD for ; Mon, 24 Apr 2023 03:57:19 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ua1-x936.google.com with SMTP id a1e0cc1a2514c-76fd0036c7fso901009241.3 for ; Sun, 23 Apr 2023 20:57:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20221208.gappssmtp.com; s=20221208; t=1682308639; x=1684900639; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=OR8Ew9m+sVQZq/TB1Sll3UQ3zTbig0mDLWXr6/K7C8E=; b=lusQd+xP6+sQC37E58DGXfdsFb3CxLyXUKQmGniimZpRhe+V1rumflojEe4PKZaXV+ zcFI4NovEJvcCX/0T6b2QEkYBybaAR6oclaqii+Ztlws/Fq1glQezuXXt+8EKC1Jztua a0ynSKmNfuBAlT/LDmGtoV7zyz8N6ARFzsaOSqA01RJrK7mMEvffv4PTovP+4K10q56S DGbezhIYWXhlDp0sw9wZuBGOc3JjoKb3tDd8NMim8C4R3HRb7ASF2WOoyfDJ2F5QfcpE 7riTgOi5mp4HPQ0see9kObWdnr5CHo+QcP7/w/c/5liLTd02oeUqeTe9lgzQNW7W1C4h UWTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682308639; x=1684900639; 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=OR8Ew9m+sVQZq/TB1Sll3UQ3zTbig0mDLWXr6/K7C8E=; b=IKEfpp++rcoa/AYoN9Uyv1CT0tJlcmBOjRYiuck8/9zRZ/7TtYPM61/Bzwy4HKyPFI vAzMjxwuqxh0RwgXKnFZHkFbOU6QKsIybUxrry2KXFPuZyUifzEadZvjSqfCSSloXFwg Qcu3igVY2AXlmUlQdMqhEMDbZ6Ji+SqTvPQmZnZctvBmmzPoFEvTCFDazCd0MGeMNdNa jtUMtf6TD0wEf7BYlRvn45mNiAWflShVze0o67WcsTVrMnIbCH1iz4QUxYUc2DvEk1q5 pLAAn/tXFMPjC135PPc1B/FLNOAgQTEmiOKpmVkWSfi4+JzAgIkK8SDgrKeRBRdrFxrr niBw== X-Gm-Message-State: AAQBX9eP8bNvX4XjDfdO7K9DZCVad9HbhZO6jXETl8Gt06D5jFDqDT2a MvwjZPsGm01zf6BHOFukdprYmqqiXSUBQa1ACXKmmQ== X-Google-Smtp-Source: AKy350bUUf+y/xKomVF9YXMbBEqUWBYJUJiFbnW0Hq1y+3Cd9nW/MPXewI5RUx+VXHa8feAdpy0CHvxv0e5p4kACnUU= X-Received: by 2002:a1f:d4c2:0:b0:43f:c71d:f027 with SMTP id l185-20020a1fd4c2000000b0043fc71df027mr2888968vkg.12.1682308638669; Sun, 23 Apr 2023 20:57:18 -0700 (PDT) List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@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: <90353.1682307584@kaos.jnpr.net> From: Warner Losh Date: Sun, 23 Apr 2023 21:57:06 -0600 Message-ID: Subject: Re: /lib/libc.so.7 vs. __libc_start1@FBSD_1.7 in main [so: 14] recently ? To: "Simon J. Gerraty" Cc: Mark Millard , FreeBSD Toolchain , Current FreeBSD Content-Type: multipart/alternative; boundary="000000000000cf90b005fa0d0062" X-Rspamd-Queue-Id: 4Q4WYC6qfgz3sxD 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 --000000000000cf90b005fa0d0062 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 run > a tool on the host to generate something. > When trying to build 14.0 on a 13.1 host each of those tools failed 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. 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. > 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 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 things, > ideally those tools would be built in a subdirectory of sh, csh etc, 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 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). Warner --000000000000cf90b005fa0d0062 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Apr 23, 2023 at 9:40=E2=80=AF= PM 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 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 run
a tool on the host to generate something.
When trying to build 14.0 on a 13.1 host each of those tools failed 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. If you were running the 14 binar= ies on 13 as part of the
build process, the path is messed up. I&= #39;m not surprised for dirdep
since it doesn't do all the st= aging activities that buildworld.
=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= matched set of
binary and libraries when t= he host one isn't good enough. I think it's a path
issue you are seeing...
Also, "copy" isn't a physi= cal copy because macos hates copied binaries due to security concerns.
<= /div>
=C2=A0
The DIRDEPS_BUILD uses a pseudo MACHINE "host" to deal with such = things,
ideally those tools would be built in a subdirectory of sh, csh etc, 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 not.

Yea, buildworld deals with this by creating n= ew binaries and installing them in
a special directory, which is = somewhat similar (though we always build
them rather than on dema= nd like dirdep hopes to do).=C2=A0

Warner
--000000000000cf90b005fa0d0062--