GNU bug report logs - #77476
[PATCH] Rename various hash functions to avoid clashing with GnuTLS.

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Greg A. Woods" <woods <at> robohack.ca>, Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 77476 <at> debbugs.gnu.org
Subject: bug#77476: [PATCH] Rename various hash functions to avoid clashing with GnuTLS.
Date: Fri, 04 Apr 2025 13:40:50 +0300

> Date: Thu, 03 Apr 2025 13:00:57 -0700
> From: "Greg A. Woods" <woods <at> robohack.ca>
> Cc: 77476 <at> debbugs.gnu.org
> 
> > > * 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.