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

From: Eli Zaretskii <[email-masked]>
Date: Fri, 04 Apr 2025 13:40:50 +0300

> Date: Thu, 03 Apr 2025 13:00:57 -0700
> From: "Greg A. Woods" <[email-masked]>
> Cc: [email-masked]
> 
> > > * src/fns.c: et al (hash_string, hash_lookup, hash_lookup_get_hash,
> > >   hash_put, hash_remove_from_table): Rename with a leading "lisp_" prefix.
> >
> > Sorry, can you tell more about the rationale?  Why do these clash?
> 
> What do you mean by "Wny do these clash?"???  There are identical
> symbols in the GnuTLS library to some defined in Emacs, yet the
> implementations in each are entirely different and incompatible, and so
> they can't be static-linked into the same program.  I.e. they "clash".
> 
> The problematic symbols are actually from "imported" gnulib functions
> that are included in separate .o's in libgnutls.a, but since they are
> needed by other functions in libgnutls then they have to be loaded, but
> of course this is C and there are no namespaces (at least not without
> fudging it with global structures containing function pointers, or using
> the preprocessor and avoiding separate compilation, but GnuTLS clearly
> doesn't do either) to prevent them from clashing with already loaded
> functions from the application itself and the linker rightfully gives up
> and fails.
> 
> There are only two (hash_lookup() and hash_string()) that actually
> clash, but it seems best to rename all the related global functions.

I know the theory, but we are using GnuTLS with Emacs for many years,
so I wonder how come this never came up before.

So I guess my question was why do they clash in your case, and why
didn't anyone complain until now?

AFAICT, the functions hash_look up and hash_string are actually part
of Gnulib, and GnuTLS uses those Gnulib functions.  Is that what you
see?

> Static linking really should be mandated for all C programs, at least as
> a primary test, to be sure you always get what you think you're looking
> for and so that you really know the full extent of absolutely everything
> you're depending on.

So this problem happens for you because you link Emacs statically with
GnuTLS?  And if you use GnuTLS as a shared library, the problem
doesn't happen, is that right?

> > Is this perhaps a matter of correct function visibility in a library?
> 
> There's no such thing as "function visibility" in a plain old static C
> library.

So this is again due to your use of static linking?

> I don't know if this problem can affect dynamic-linked versions of Emacs
> or not, but presumably not or bugs would have shown up by now.  I dunno
> -- the runtime dynamic linker is too much of a mysterious force to know
> for sure what it has done without dissecting exactly the result after
> the fact, and that's much harder to do as none of the implementations I
> know of have an option to produce a link map.

Paul, what are your views on this issue, and WDYT we should do about
this?

> In any case I think fixing the problems in GnuTLS is a far more
> extensive and complex job, and it's not even a tiny bit interesting to
> me as I have no vested interest in directly working on GnuTLS.  My
> interest is far higher in Emacs!  I would guess the whole method of
> importing gnulib functions would have to be changed in order to give
> those "private" (i.e. less-likely-to-ever-clash) names.
> 
> I'm happy to use GnuTLS in Emacs if that's what Emacs developers would
> like to use, but I've also been relatively happy with using the tls
> package to access an external implementation as well (though it is
> tricky to maintain with constant changes in the command-lines and output
> formats).
> 
> > Also, how come this comes up only now?
> 
> I've been avoiding linking GnuTLS for quite some time, but with the tls
> package being deprecated for a while now (my primary production Emacs is
> now 27.2, tls.el moved to obsolete in 27.1) that's becoming a precarious
> position to take.

Yes, but others are using GnuTLS since many Emacs 26, so any such
build problems should have been reported many years ago.