From nobody Mon Apr 24 04:02:01 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 4Q4Wft2cGcz46wnF for ; Mon, 24 Apr 2023 04:02:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vk1-xa2b.google.com (mail-vk1-xa2b.google.com [IPv6:2607:f8b0:4864:20::a2b]) (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 4Q4Wft0Hkfz42Pk for ; Mon, 24 Apr 2023 04:02:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-vk1-xa2b.google.com with SMTP id 71dfb90a1353d-440403d3517so1582053e0c.0 for ; Sun, 23 Apr 2023 21:02:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20221208.gappssmtp.com; s=20221208; t=1682308933; x=1684900933; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=RVpXm0/fGiXnIlhWmz7XpyuzFFAICEpNzBBis90bilw=; b=CPoKUQTF18f4qQjq+oamkzq1TMkOqzIN8aMjohwoMnREKwOQaVw+KCLDDsPmowl99q buERs4D4Zi94Oob+WXvc6NaL8d1BQCpRpxS6CJIpl+dSvBAX2adAMZjeAKl5AclhI8GE MlyqFzrrcUJWNIlau34sA4P5RS49uXbbnRRNhNeykCTldnpBBibCHkcxOep6G4fHrvNl FwkA0yPmgyJtwGEl1UdDc8GTzzVihA7Ew3Zq9dCXdcPjCQ/P+R9aMb9QkLEtt+2AiqSB V51frnTQV34ryDJPVQdvNEhoCHVNO+mSZ3M2c1arD/wq5P9/NpC4288a33fbLwJKysnW G0DA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682308933; x=1684900933; 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=RVpXm0/fGiXnIlhWmz7XpyuzFFAICEpNzBBis90bilw=; b=FdYH0l4GmVdXjdEbDtWPoa0I5Blvi8gE7rZpN80sch7QEwrZXemMr1qcjq/+AT/cMR arlRafXdSNV05IfYcjRgdLN5lK4ugFRXTF8+CxkqXZhtvYgMsXdK0IWPY4s8TRDSdWLs 64o1NJdmZScGV//XAPdu39furlsmqyawj+UDStjrmJ3eOaXuLAJwb+2ddQA9iCc/HcAH aH4CsnoTuQjpDBratdXrQHsj1e9ZvbVkr9LK9mE2D5lacxkvjpbbP4ScIUeA7gRZuT17 UB2UwfjJtW9xGHPPpHbDIolY78L2CrLY95R114Hqv69r9Kb2xfZgjHxSiNyaKLeZPZxg XMTQ== X-Gm-Message-State: AAQBX9e+U9VFojvEilJXyvXL8QvMFJ8ZGmQCFZkV6gTklQvQDeW/f3P3 uXIs2EQ5gHOaZwbBnwd8zacI4P8mEUaaqW1aiO97kH2vzyfkErNC X-Google-Smtp-Source: AKy350be4n3AoJR7bJ2wY1Ol/PGjaApErR4gaN0CH16C6lKnBqWv3R6sEUA6PdOLLHS492UY9E6Yjtu+m87W/3JAdGA= X-Received: by 2002:a1f:4a45:0:b0:440:2c18:faf with SMTP id x66-20020a1f4a45000000b004402c180fafmr2737580vka.16.1682308933173; Sun, 23 Apr 2023 21:02:13 -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> In-Reply-To: <5B26AB25-075F-4630-86C1-886E6082CDCF@yahoo.com> From: Warner Losh Date: Sun, 23 Apr 2023 22:02:01 -0600 Message-ID: Subject: Re: /lib/libc.so.7 vs. __libc_start1@FBSD_1.7 in main [so: 14] recently ? To: Mark Millard Cc: FreeBSD Toolchain , Current FreeBSD Content-Type: multipart/alternative; boundary="0000000000005d57a805fa0d129d" X-Rspamd-Queue-Id: 4Q4Wft0Hkfz42Pk 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 --0000000000005d57a805fa0d129d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Apr 23, 2023 at 9:09=E2=80=AFPM Mark Millard wr= ote: > 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= " > > Does this mean that a /lib/libc.so.8 is pending? Or do the > criteria for the likes of /lib/libc.so.7 allow for new > symbols over time without a name change, even after a > release contains a /lib/libc.so.7 ? > We offer backwards compatibility in libc (so new libc will work with an old binary) but not forward compatibility (so new binary old libc may not work). This policy allows us to add symbols to libc, but never delete them. It also lets us have new versions of old symbols (like stat). > Just curious about the criteria. Executing newer on older is > not my normal type of activity: usually avoided. > Yea. New binary on old libc isn't supported. Similar rules apply to the kernel, but there's a "window" for forward compat when it impacts the upgrade path. Warner > FYI: Checking 13.2-RELEASE shows it is using /lib/libc.so.7 : > > # uname -apKU > FreeBSD generic 13.2-RELEASE FreeBSD 13.2-RELEASE > releng/13.2-n254617-525ecfdad597 GENERIC arm64 aarch64 1302001 1302001 > > # ldd -a `which git` > /usr/local/bin/git: > libpcre2-8.so.0 =3D> /usr/local/lib/libpcre2-8.so.0 (0x6a226ba020= 00) > libz.so.6 =3D> /lib/libz.so.6 (0x6a226c8fb000) > libintl.so.8 =3D> /usr/local/lib/libintl.so.8 (0x6a226cc81000) > libthr.so.3 =3D> /lib/libthr.so.3 (0x6a226d429000) > libc.so.7 =3D> /lib/libc.so.7 (0x6a226dbfa000) > /usr/local/lib/libpcre2-8.so.0: > libthr.so.3 =3D> /lib/libthr.so.3 (0x6a226d429000) > libc.so.7 =3D> /lib/libc.so.7 (0x6a226dbfa000) > /lib/libz.so.6: > libc.so.7 =3D> /lib/libc.so.7 (0x6a226dbfa000) > /usr/local/lib/libintl.so.8: > libc.so.7 =3D> /lib/libc.so.7 (0x6a226dbfa000) > /lib/libthr.so.3: > libc.so.7 =3D> /lib/libc.so.7 (0x6a226dbfa000) > > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > > > --0000000000005d57a805fa0d129d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Apr 23, 2023 at 9:09=E2=80=AF= PM Mark Millard <marklmi@yahoo.com<= /a>> 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"

Does this mean that a /lib/libc.so.8 is pending? Or do the
criteria for the likes of /lib/libc.so.7 allow for new
symbols over time without a name change, even after a
release contains a /lib/libc.so.7 ?


Just curious about the criteria. Executing newer on older is
not my normal type of activity: usually avoided.

<= /div>
Yea. New binary on old libc isn't supported.

Similar rules apply to the kernel, but there's a "window&= quot; for forward
compat when it impacts the upgrade path.
<= div>
Warner
=C2=A0
FYI: Checking 13.2-RELEASE shows it is using /lib/libc.so.7 :

# uname -apKU
FreeBSD generic 13.2-RELEASE FreeBSD 13.2-RELEASE releng/13.2-n254617-525ec= fdad597 GENERIC arm64 aarch64 1302001 1302001

# ldd -a `which git`
/usr/local/bin/git:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 libpcre2-8.so.0 =3D> /usr/local/lib/libpcre2= -8.so.0 (0x6a226ba02000)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 libz.so.6 =3D> /lib/libz.so.6 (0x6a226c8fb00= 0)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 libintl.so.8 =3D> /usr/local/lib/libintl.so.= 8 (0x6a226cc81000)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 libthr.so.3 =3D> /lib/libthr.so.3 (0x6a226d4= 29000)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 libc.so.7 =3D> /lib/libc.so.7 (0x6a226dbfa00= 0)
/usr/local/lib/libpcre2-8.so.0:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 libthr.so.3 =3D> /lib/libthr.so.3 (0x6a226d4= 29000)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 libc.so.7 =3D> /lib/libc.so.7 (0x6a226dbfa00= 0)
/lib/libz.so.6:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 libc.so.7 =3D> /lib/libc.so.7 (0x6a226dbfa00= 0)
/usr/local/lib/libintl.so.8:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 libc.so.7 =3D> /lib/libc.so.7 (0x6a226dbfa00= 0)
/lib/libthr.so.3:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 libc.so.7 =3D> /lib/libc.so.7 (0x6a226dbfa00= 0)

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


--0000000000005d57a805fa0d129d--