Subject: Re: bug#77476: [PATCH] Rename various hash functions to avoid clashing with GnuTLS.

From: Eli Zaretskii <[email-masked]>
Date: Sun, 20 Apr 2025 11:04:19 +0300

> Date: Sat, 19 Apr 2025 22:32:44 -0700
> Cc: [email-masked], [email-masked]
> From: Paul Eggert <[email-masked]>
> 
> 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.

Ah, okay.  So this is a clash of Gnulib with itself, due to incorrect
visibility specs applied by GnuTLS...

> 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 
> <https://gitlab.com/gnutls/gnutls/-/issues/1703>.
> 
> 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.

Thanks.

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

I agree.