[gnutls-devel] GnuTLS | GnuTLS static library wrongly exports private symbols (#1703)

[Read-only notification of GnuTLS library development activities]

Paul Eggert commented: https://gitlab.com/gnutls/gnutls/-/issues/1703#note_2462799471


Thanks for the fix.

On the Emacs side I installed into Emacs master a [patch](https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=c8eed90eb4d0583dc3463edfad176b9d3f98d11f) that renames the Emacs functions `hash_lookup` and `hash_string` so that they no longer collide with the like-named Gnulib functions that GnuTLS brings in when linked statically. So this means the problem goes away if you either (a) use bleeding-edge Emacs, (b) use bleeding-edge GnUTLS with !1949 or (c) use dynamic linking which almost everybody uses anyway.

>From my point of view this is good enough, so I'll close the GnuTLS issue (I already closed the [Emacs bug report](https://debbugs.gnu.org/cgi/bugreport.cgi?bug=77476)).

As for future coordination, if I understand correctly this would mean that Emacs should not use any symbol exported from any Gnulib module, even modules that Emacs developers don't use and don't know about. That's probably a bridge too far. I expect we'll settle for what we have now, which is ad hoc fixes whenever problems like this turn up in practice.

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1703#note_2462799471
You're receiving this email because of your account on gitlab.com.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20250422/d18efe82/attachment.html>