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

Previous Next

Full log

Message #24 received at 77476 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: eggert <at> cs.ucla.edu
Cc: 77476 <at> debbugs.gnu.org, woods <at> robohack.ca
Subject: Re: bug#77476: [PATCH] Rename various hash functions to avoid clashing
 with GnuTLS.
Date: Sat, 19 Apr 2025 16:50:12 +0300

Ping!  Paul, could you please chime in, since these are Gnulib
functions we're talking about.

> Cc: 77476 <at> debbugs.gnu.org
> Date: Fri, 04 Apr 2025 13:40:50 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > 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.