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?
> >
> > 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?
--
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
