Date: Thu, 24 Jul 2025 15:43:21 -0400 From: John Baldwin <jhb@FreeBSD.org> To: Cy Schubert <Cy.Schubert@cschubert.com> Cc: Cy Schubert <cy@FreeBSD.org>, src-committers@FreeBSD.org, dev-commits-src-all@FreeBSD.org, dev-commits-src-main@FreeBSD.org Subject: Re: git: ae07a5805b19 - main - krb5: Add version maps Message-ID: <e4aa1829-84b6-4877-a43a-9451dc916b86@FreeBSD.org> In-Reply-To: <20250724191732.E8ADF54D@slippy.cwsent.com> References: <202507221548.56MFmoo2060272@gitrepo.freebsd.org> <7d7427f3-16c2-4948-ab28-56eec1677e13@FreeBSD.org> <ae6cacb8-26e2-441e-983b-a42f8db148ae@FreeBSD.org> <20250724191732.E8ADF54D@slippy.cwsent.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 7/24/25 15:17, Cy Schubert wrote: > In message <ae6cacb8-26e2-441e-983b-a42f8db148ae@FreeBSD.org>, John Baldwin > wri > tes: >> On 7/23/25 10:00, John Baldwin wrote: >>> On 7/22/25 11:48, Cy Schubert wrote: >>>> The branch main has been updated by cy: >>>> >>>> URL: https://cgit.FreeBSD.org/src/commit/?id=ae07a5805b1906f29e786f415d67b >> ef334557bd3 >>>> >>>> commit ae07a5805b1906f29e786f415d67bef334557bd3 >>>> Author: Cy Schubert <cy@FreeBSD.org> >>>> AuthorDate: 2025-07-22 15:38:19 +0000 >>>> Commit: Cy Schubert <cy@FreeBSD.org> >>>> CommitDate: 2025-07-22 15:48:40 +0000 >>>> >>>> krb5: Add version maps >>>> >>>> Shared objects must have version maps. These were copied from upstre >> am's >>>> *.exports files. >>>> >>>> Reminded by: kib >>>> Fixes: ee3960cba106 >>> >>> Hmmm, does this match the version files built by upstream's build? They >>> seem to use a different pattern for the version numbers in their build >>> glue and include a trailing HIDDEN annotation. > > This doesn't match upstream's versioning. That would cause the version > numbers to go backwards. I used the OpenSSL 1.1.1 update as the example. It > also mitigates any conflict between the MIT ports and base. > > Does this make sense? No, SHLIB_MAJORs and symbol versions are _not_ the same thing. It isn't clear to me why you need to use custom _symbol_ versions. Also, there isn't really a notion of the numbers going backwards. All the versions are just treated as strings without doing any numerical comparisons. The runtime loader doesn't decide to load libfoo.so.(N+1) instead of libfoo.so.N if it finds the N+1 version in the filesystem. The string "libfoo.so.N" is hardcoded in the binary's DT_NEEDED and the runtime loader only looks for that exact file. Similarly, symbol versions are just strings. We tend to follow a pattern to make it easier for the humans to parse, but there's no reason that the symbol versions need to have any relation at all between Heimdal and MIT. And in general, you could rename/rework all the versions of any library anytime you bump SHLIB_MAJOR. Symbol versions are only meaningful to handle ABI changes in a library while both the old and new libraries still have the same SHLIB_MAJOR. >>> binutils.versions: $(SHLIB_EXPORT_FILE) Makefile >>> base=`echo "$(LIBBASE)" | sed -e 's/-/_/'`; \ >>> echo > binutils.versions "$${base}_$(LIBMAJOR)_MIT {" >>> sed >> binutils.versions < $(SHLIB_EXPORT_FILE) "s/$$/;/" >>> echo >> binutils.versions "};" >>> echo >> binutils.versions "HIDDEN { local: __*; _rest*; _save*; * >> ; };" >>> >>> (SHLIB_EXPORT_FILE is the foo.exports file) >>> >>> Upstream only uses those for Linux but the binutils versions file is the >>> right format to use with both ld.bfd and lld. >>> >>> I also wonder if it would be better to use similar logic to generate these >>> files at build time? We have some other version maps we generate as build >>> artifacts rather than checking into the tree IIRC. >> >> While I appreciate that you committed a change, I do think it would be useful >> to answer the questions above. For example, why not generate the maps at >> runtime to reduce the chances they would get out of sync in future vendor >> imports? There are probably reasonable thoughts on both sides, but we should >> at least discuss them. >> >> Also, I echo requests from both Jessica and Kostik: please post patches for >> review. We have time before 15.0 so we can slow down a bit and use discussio >> n >> and review to arrive at the right changes going forward rather than a flurry >> of commits that keep fixing each other. > > Sure. > > What is the consensus then? Do we want to use upstream's DSO numbering or > our own, like we do with OpenSSL? I think there are several orthogonal questions: 1) Do we want to use upstream symbol versioning maps with upstream symbol versions? 2) If yes to 1, do we check in those maps and rely on updating the maps as part of each vendor import, or do we generate the maps from the exports files during the build in .OBJDIR as part of each build? 3) Which SHLIB_MAJOR (_not_ the same thing as the versions used in version maps) should the libraries use? I think we can ignore the current bumpiness of this week, but we need to ensure that any shared library with the same filename as Heimdal is using a different SHLIB_MAJOR for MIT. If you already bumped from .9 or whatever to .121 then that's probably fine and I don't think we need another bump on main. The people that upgraded world this week just need to ensure they have rebuilt to the latest once we've settled what the questions are. The main end goal is that we need to ensure we do not break the ABI for upgrades from 14.x (or even people who are on 15 from last week and still have heimdal) rather than people who upgraded during this week's chaos. This does mean that OptionalObsoleteFiles.inc should be listing all of the heimdal libraries effectively? There shouldn't be any libraries whose name and SHLIB_MAJOR are the same between Heimdal and MIT? Note that adding symbol versioning normally counts as its own ABI break and generally requires bumping SHLIB_MAJOR, but we can roll that all into the switch to MIT and just pretend like the versions were enabled from the beginning. A separate question though is if the SHLIB_MAJOR from base should match what is installed from ports. OpenSSL is a probably a good reference case here, and we may want to follow the model it uses. I can't recall if we purposely use the same SHLIB_MAJOR in base as ports for the same OpenSSL versions or if we use a different SHLIB_MAJOR. It looks like we use different versions (e.g. /usr/lib/libssl.so.3 in base vs libssl.so.12 for security/openssl in ports). I'm not sure what we expect the behavior to be for users on 15 and kerberos in ports. Do we expect some users to use MIT kerberos from ports? If so, should that library override the base system libraries even for base system applications? OpenSSL seems to be following a model where base system components always use the base system OpenSSL, but ports can choose to use a ports OpenSSL instead of the base system OpenSSL. However, for that to work, the ports OpenSSL has to use a different SHLIB_MAJOR so the runtime loader doesn't just use the base system OpenSSL instead for ports linked against the ports OpenSSL. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?e4aa1829-84b6-4877-a43a-9451dc916b86>