In message <e4aa1829-84b6-4877-a43a-9451dc916...@freebsd.org>, John Baldwin
wri
tes:
> 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=ae07a5805b1906f29e786f415d6
> 7b
> >> 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 ups
> tre
> >> 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 clea
> r
> 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 ge
> neral,
> 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.
Noted.
>
> >>> 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 thes
> e
> >>> files at build time? We have some other version maps we generate as buil
> d
> >>> artifacts rather than checking into the tree IIRC.
> >>
> >> While I appreciate that you committed a change, I do think it would be use
> ful
> >> 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 sho
> uld
> >> at least discuss them.
> >>
> >> Also, I echo requests from both Jessica and Kostik: please post patches fo
> r
> >> review. We have time before 15.0 so we can slow down a bit and use discus
> sio
> >> n
> >> and review to arrive at the right changes going forward rather than a flur
> ry
> >> 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?
Probably. But the input to the upstream scripts results in a duplication of
symbols in libkrb5profile and libkrb5. Whatever we/I build will need to
remove those. I have the crude beginnings of such a script here. Certainly
not ready to share with anyone yet.
>
> 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 bumpin
> ess
> 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 yo
> u
> 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 wor
> ld
> 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 ens
> ure
> 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 th
> e
> heimdal libraries effectively? There shouldn't be any libraries whose
> name and SHLIB_MAJOR are the same between Heimdal and MIT?
The libraries in OptionalObsoleteFiles.inc were versioned so there would be
no overlap. The .121 version made that simpler.
Note that when Heimdal is finally removed this complexity goes away.
>
> 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.
Noted.
>
> 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 i
> f
> 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 t
> o
> 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.
We do use a different version number in base and ports. The port uses 12
while base uses 30.
>
> --
> John Baldwin
There were a lot of problems with the linking against the different
Kerberos (MIT and Heimdal in ports and base) in the past. This was fixed
ten or more years ago.
People will still want to install the MIT port to host the KDC database
using LDAP. One should be able to build OpenLDAP now with MIT in base, then
build the MIT flavour in ports depending on OpenLDAP.
--
Cheers,
Cy Schubert <cy.schub...@cschubert.com>
FreeBSD UNIX: <c...@freebsd.org> Web: https://FreeBSD.org
NTP: <c...@nwtime.org> Web: https://nwtime.org
e**(i*pi)+1=0
