On 2025-04-19 06:50, Eli Zaretskii wrote: > Paul, could you please chime in, since these are Gnulib > functions we're talking about. GnuTLS incorrectly exports some Gnulib functions to the outside world, and this breaks programs that use these function names for their own purposes. Gnulib has a way to fix this: its lib-symbol-visibility module. GnuTLS should use this (or do the equivalent by hand), but doesn't. I suppose GnuTLS has other visibility problems like this, and they should all be fixed. I filed a bug report with the GnuTLS folks about this; see . Possibly this problem even affects normal (i.e., dynamically linked) Emacs on some platforms. As Greg says, the semantics of name clashes is not portable, and I am particularly worried about what would happen if dynamically loaded modules refer to the clashing names on some random platform. As we can't expect GnuTLS to fix their bug soon, or for all our users to update to the fixed GnuTLS version soon, we should change the Emacs names to avoid the clash in the meantime. It's just two names so I did that, by installing the attached patch on master. I changed "hash_string" to "hash_char_array" which is a more accurate name as the argument is not a C string, and I changed "hash_lookup" to "hash_find" which is a bit shorter. I also changed two other names to match. I doubt whether this patch is urgent enough to backport to the emacs-30 branch. Hardly anybody links statically; the GnuTLS build procedure even warns against doing static linking (due to other static-linking problems that Emacs does not run into). And most likely, dynamically-linked modules won't use the clashing symbols. Marking the bug as done.