aboutsummaryrefslogtreecommitdiffstats
path: root/java
diff options
context:
space:
mode:
authorPaul Eggert2025-04-19 18:44:52 -0700
committerPaul Eggert2025-04-19 19:31:26 -0700
commitc8eed90eb4d0583dc3463edfad176b9d3f98d11f (patch)
tree2fb288a90f4dd07d3d08c43bbb63feced72189de /java
parent71ee484cac3e0e5b68f006b4cca81c13ca6ce11e (diff)
downloademacs-c8eed90eb4d0583dc3463edfad176b9d3f98d11f.tar.gz
emacs-c8eed90eb4d0583dc3463edfad176b9d3f98d11f.zip
Avoid name clashes with static GnuTLS
Work around a bug in GnuTLS 3.7.11 and earlier: when built statically, its mistakenly exports symbols hash_lookup and hash_string, which collide with Emacs symbols of the same name, preventing temacs from linking statically. Problem reported by Greg A. Woods (Bug#77476). Because GnuTLS never uses hash_lookup or hash_string this issue ordinarily doesn’t seem to prevent temacs from linking to GnuTLS on GNU/Linux, as it’s linked dynamically and the dynamic linker never needs to resolve references to either symbol. However, I suppose a clash or bug could occur even with dynamic linking if Emacs later loads a module that uses either symbol. Although GnuTLS should be fixed, Emacs should link statically to current and older GnuTLS versions in the meantime, and it should avoid potential problems with dynamic linking. Renaming the two clashing names is an easy way to do this. For consistency with the new name for hash_lookup, also rename hash_lookup_with_hash and hash_lookup_get_hash. * src/fns.c (hash_find_with_hash): Rename from hash_lookup_with_hash. (hash_find): Rename from hash_lookup. (hash_find_get_hash): Rename from hash_lookup_get_hash. (hash_char_array): Rename from hash_string. All uses changed.
Diffstat (limited to 'java')
0 files changed, 0 insertions, 0 deletions