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

[Greg A. Woods]

At Fri, 04 Apr 2025 13:40:50 +0300, Eli Zaretskii <eliz@gnu.org> wrote:
Subject: Re: bug#77476: [PATCH] Rename various hash functions to avoid clashing 
with GnuTLS.
>
> I know the theory, but we are using GnuTLS with Emacs for many years,
> so I wonder how come this never came up before.

Sorry, but apparently you don't know the _practice_.  Theory is one
thing, but actually doing it in practical terms is necessary to fully
understand.  It'll be a light-bulb moment, I promise.  I don't mean to
be deprecating, but my initial thought on submitting this patch would be
that the problem was blindingly obvious and there would be no questions
whatsoever about the necessity of a fix -- just the colour of the bike
shed would need deciding.

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

People have apparently forgotten about the benefits of static linking
and the necessity of testing it with C programs and so it rarely gets
done.

I have come up against this problem for several years -- I just didn't
bother fixing or reporting it because using lisp/tls.el was a sufficient
workaround.  With tls.el moving to lisp/obsolete I've been prompted.

As I said, if one does not static-link a C program, at least as a test,
then one will not fully understand and appreciate all of the
dependencies and all of their interactions.  This is a necessary caveat
due to the lack of namespaces in C.

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

Indeed, that's what I reported, and what my submitted patch fixes, since
of course without my patch there are obviously also identically named
functions in Emacs.  Here's proof of a sort that the patch works:

$ ll build-x86_64-nb9.99.81/src/emacs
276416 -rwxr-xr-x  2 woods  wheel  - 141404440 Apr  2 12:44 
build-x86_64-nb9.99.81/src/emacs
$ size build-x86_64-nb9.99.81/src/emacs
   text    data     bss     dec     hex filename
19149051         358196 2911673 22418920        15615e8 
build-x86_64-nb9.99.81/src/emacs
$ file build-x86_64-nb9.99.81/src/emacs
build-x86_64-nb9.99.81/src/emacs: ELF 64-bit LSB executable, x86-64, version 1 
(SYSV), statically linked, for NetBSD 9.99.81, with debug_info, not stripped
$ build-x86_64-nb9.99.81/src/emacs --version
GNU Emacs 31.0.50
Development version a72cfc52cc36 on master branch; build date 2025-04-02.
Copyright (C) 2025 Free Software Foundation, Inc.
GNU Emacs comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of GNU Emacs
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.
$ build-x86_64-nb9.99.81/src/emacs --batch --eval '(if (gnutls-available-p) 
(message "has GnuTLS"))'
has GnuTLS

You can't have two different and incompatible implementations of a
function in the same C program when they both have the same identifier.
The runtime dynamic linker hides this problem from the average user and
papers over it hoping nothing goes wrong.  Usually it works well enough
that nothing invokes undefined behaviour.  I never bet on it being
correct though.

Maybe it would be a good idea for you to try static-linking Emacs.

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

I would guess not, though that's based on my experience from a different
platform (macOS) where I have no problems dynamic-linking GnuTLS, but
that's not the platform where I always static-link things (NetBSD).  So,
I don't really know -- I avoid shared libraries as much as possible, and
almost entirely on NetBSD always, but of course on macOS that's
impossible.  However on macOS the entire object format is different and
the dynamic linker is also a completely unique implementation, so I
can's speak personally to the results with GNU ld(1) and NetBSD ld_elf.so.

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

I doubt it.  Most people don't even seem to know the difference between
static linking and dynamic runtime linking any more.  They just type
"make".

--
                                        Greg A. Woods <gwoods@acm.org>

Kelowna, BC     +1 250 762-7675           RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>     Avoncote Farms <woods@avoncote.ca>

pgp36KwqaFYzI.pgp
Description: OpenPGP Digital Signature