Hey! This is something of a bug report; I can't figure out how to create a BugZilla account. Context: Linux, x86_64, Jogl 2.5.0 from
https://jogamp.org/deployment/maven/, OpenJDK 1.17, Debian Testing/trixie, glibc 2.37-15, coding in Clojure but that shouldn't be relevant to this problem.
I've been doing some work with JOGL for fun and I was trying to create 1 big JAR file with code & native libs. In the JAR there are the usual native libraries (eg, libglugen_rt.so) in natives/linux-amd64/*.so. When I try to execute the jar with `java -jar blah.jar` the JVM segfaults (!) with a proper "A fatal error has been detected by the Java Runtime Environment: SIGSEGV (0xb) at pc=0x00007f05c3ef9d3a, pid=145557, tid=145558".
I've been investigating the issue to try and understand what is going wrong. I'm no expert at dynamic linking so I might get some of the terminology wrong, so please be forgiving when I do. It appears that the native library unpacking is working (eg, with `-Djogamp.debug=true` I can see "JarUtil: EXTRACT[3]: [gluegen_rt -> ] natives/linux-amd64/libgluegen_rt.so -> /tmp/jogamp_0000/file_cache/jln3000201349121303511/jln11359409541745748337/natives/linux-amd64/libgluegen_rt.so: 18424 bytes, addedAsNativeLib: false".
However, the custom dynamic library loading done by gluegen seems to be disagreeing with the ld.so. I'm referring to a specific core dump but the problem is probably more pervasive. libgluegen_rt.so is loading with key pointers set relative to the library on disk (so small values like pointers to 0x109e). ld.so refers to that information later in the process (loading libjawt.so in my case) and has logic to assume that pointers have been patched (eg, 0x7f51ebe6d09e with the shared lib starting at memory address 0x7f51ebe6c000). When it dereferences to the small value pointers, I get my SIGSEGV.
ld.so decides if the patch has been done using `!(l->l_ld_readonly || DL_RO_DYN_SECTION)`. In this case, what jogamp loads into memory has l_ld_readonly set to false and DL_RO_DYN_SECTION appears to be hardcoded to 0. ld.so then assumes that the dynamic section of the library has already been patched on load. This logic is in sdeps/generic/ldsodefs.h:dl_relocate_ld of glibc.
I haven't dug into Gluegen to figure out what is happening on that side of the fence; but I assume some flag is being mis-set that should indicate a read-only shared library. Or if I'm lucky I've mis-built the JAR somehow. What I have now seems like enough to flag it on Jogamp.org though since it is a tricky one to debug and someone else might run into the same problem.
Locked
