Re: git: ae07a5805b19 - main - krb5: Add version maps

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?

> > 
> > 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.Schubert@cschubert.com>
FreeBSD UNIX:  <cy@FreeBSD.org>   Web:  https://FreeBSD.org
NTP:           <cy@nwtime.org>    Web:  https://nwtime.org

			e**(i*pi)+1=0