On 7/24/25 15:17, Cy Schubert wrote:
In message <ae6cacb8-26e2-441e-983b-a42f8db14...@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 <c...@freebsd.org>
AuthorDate: 2025-07-22 15:38:19 +0000
Commit: Cy Schubert <c...@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
