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=ae07a5805b1906f29e786f415d67bef334557bd3

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 upstream'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.

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 discussion
and review to arrive at the right changes going forward rather than a flurry
of commits that keep fixing each other.

--
John Baldwin


Reply via email to