At Fri, 04 Apr 2025 13:40:50 +0300, Eli Zaretskii 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 Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms