Date: Sun, 23 Apr 2023 22:02:01 -0600 From: Warner Losh <imp@bsdimp.com> To: Mark Millard <marklmi@yahoo.com> Cc: FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, Current FreeBSD <freebsd-current@freebsd.org> Subject: Re: /lib/libc.so.7 vs. __libc_start1@FBSD_1.7 in main [so: 14] recently ? Message-ID: <CANCZdfq5-CLEf0nmP0jCKv3UNoPKrEWqWOeLruJcys8wweMRZA@mail.gmail.com> In-Reply-To: <5B26AB25-075F-4630-86C1-886E6082CDCF@yahoo.com>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] On Sun, Apr 23, 2023 at 9:09 PM 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" > > 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 => /usr/local/lib/libpcre2-8.so.0 (0x6a226ba02000) > libz.so.6 => /lib/libz.so.6 (0x6a226c8fb000) > libintl.so.8 => /usr/local/lib/libintl.so.8 (0x6a226cc81000) > libthr.so.3 => /lib/libthr.so.3 (0x6a226d429000) > libc.so.7 => /lib/libc.so.7 (0x6a226dbfa000) > /usr/local/lib/libpcre2-8.so.0: > libthr.so.3 => /lib/libthr.so.3 (0x6a226d429000) > libc.so.7 => /lib/libc.so.7 (0x6a226dbfa000) > /lib/libz.so.6: > libc.so.7 => /lib/libc.so.7 (0x6a226dbfa000) > /usr/local/lib/libintl.so.8: > libc.so.7 => /lib/libc.so.7 (0x6a226dbfa000) > /lib/libthr.so.3: > libc.so.7 => /lib/libc.so.7 (0x6a226dbfa000) > > === > Mark Millard > marklmi at yahoo.com > > > [-- Attachment #2 --] <div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Apr 23, 2023 at 9:09 PM Mark Millard <<a href="mailto:marklmi@yahoo.com">marklmi@yahoo.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I will not get into why, but I executed a git built for 1400082<br> in a 1400081 world context and got what was to me a surprise,<br> given that /lib/libc.so.7 is part of 13.2-RELEASE :<br> <br> ld-elf.so.1: /usr/local/bin/git: Undefined symbol "__libc_start1@FBSD_1.7"<br> <br> Does this mean that a /lib/libc.so.8 is pending? Or do the<br> criteria for the likes of /lib/libc.so.7 allow for new<br> symbols over time without a name change, even after a<br> release contains a /lib/libc.so.7 ?<br></blockquote><div><br></div><div>We offer backwards compatibility in libc (so new libc will work with an old binary)</div><div>but not forward compatibility (so new binary old libc may not work).</div><div><br></div><div>This policy allows us to add symbols to libc, but never delete them.</div><div>It also lets us have new versions of old symbols (like stat).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Just curious about the criteria. Executing newer on older is<br> not my normal type of activity: usually avoided.<br></blockquote><div><br></div><div>Yea. New binary on old libc isn't supported.</div><div><br></div><div>Similar rules apply to the kernel, but there's a "window" for forward</div><div>compat when it impacts the upgrade path.</div><div><br></div><div>Warner<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> FYI: Checking 13.2-RELEASE shows it is using /lib/libc.so.7 :<br> <br> # uname -apKU<br> FreeBSD generic 13.2-RELEASE FreeBSD 13.2-RELEASE releng/13.2-n254617-525ecfdad597 GENERIC arm64 aarch64 1302001 1302001<br> <br> # ldd -a `which git`<br> /usr/local/bin/git:<br> libpcre2-8.so.0 => /usr/local/lib/libpcre2-8.so.0 (0x6a226ba02000)<br> libz.so.6 => /lib/libz.so.6 (0x6a226c8fb000)<br> libintl.so.8 => /usr/local/lib/libintl.so.8 (0x6a226cc81000)<br> libthr.so.3 => /lib/libthr.so.3 (0x6a226d429000)<br> libc.so.7 => /lib/libc.so.7 (0x6a226dbfa000)<br> /usr/local/lib/libpcre2-8.so.0:<br> libthr.so.3 => /lib/libthr.so.3 (0x6a226d429000)<br> libc.so.7 => /lib/libc.so.7 (0x6a226dbfa000)<br> /lib/libz.so.6:<br> libc.so.7 => /lib/libc.so.7 (0x6a226dbfa000)<br> /usr/local/lib/libintl.so.8:<br> libc.so.7 => /lib/libc.so.7 (0x6a226dbfa000)<br> /lib/libthr.so.3:<br> libc.so.7 => /lib/libc.so.7 (0x6a226dbfa000)<br> <br> ===<br> Mark Millard<br> marklmi at <a href="http://yahoo.com" rel="noreferrer" target="_blank">yahoo.com</a><br> <br> <br> </blockquote></div></div>home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfq5-CLEf0nmP0jCKv3UNoPKrEWqWOeLruJcys8wweMRZA>