From nobody Mon Apr 24 03:57:06 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 4Q4WYF1V2Pz46wYM for ; Mon, 24 Apr 2023 03:57:21 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) (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 4Q4WYC6nVhz3sqL 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-x92c.google.com with SMTP id a1e0cc1a2514c-77259202d1dso897153241.1 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=1682308638; x=1684900638; 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=Z2bjChUeJ4t0nPx1Bs0ABh++UzEF7ymXY7Nfg2MzuFh2VU+UgcSXASp/8x8br3LAhZ mHOG37S53G4NQswJsgDodWTIzY4w0J/4XWR9a2NfV+vDb0Yd8qIUYz6G6jrV7R+Dh65K jSZzTyNF8xumwjqANo0wd6LCStQXvH3hYAWhDoFwThW/EgCyxNnT/25qym31Oc0kJBKd SgigefjZ4yfab/JHDEht4SwfrZmBb//RkQVMqv0tq6Ryd4gcYSAHc2ZelaJlXCxE1+T+ gVWaSkFsKDkkriZ0JStcyq6Vyxjy9uYNFYBqCrgrRIsk1oLaUK9wregwUJ4klGt6UITp 7JsQ== 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=IzDyYreFE8UiB3P1/1VF/h0sZ3jdxGk+lBbgPR8fRusDnohw3xesoA0p04mNRARyyk 4EQsj4cpa3SMBH7bkUJkHPDMBX5uLWKFTh9RUu+4yC8phfIjvL7QzzwLJXzox4Dh+/d5 9asx/jv9QBFjYo5/sdi+VpjKttP4nbpWYqoLZqvRBOpsVaH2QBmmJxnBiZ15G6ADSRNq g4MrrSDr2X48CZN98ikGgDagU3gATEe+1SUicv4RU3IRAXaqruh7yvn0Gt0Mxsp5HrZt g6dqSBgXsefB38swiaUNi/DkeIUbUxxiG1YM0e5qhdIXCW8k5eU4nPNlv8QsM1QEyNmb N8Xg== X-Gm-Message-State: AAQBX9d9t1gofkj2MBuYXK7rmQbPJiNQP/yv1T6/3IW2pnDJANSXn62u 70AYMqq0i8xcpDcXePYW9DDoPBxRtYg1hhrReEqOlw== 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: 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: <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: 4Q4WYC6nVhz3sqL 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--