Code change:
<ins> diff --git a/hotspot/src/os/linux/vm/os_linux.cpp b/hotspot/src/os/linux/vm/os_linux.cpp index c477851c1b..ff5e28d95b 100644 --- a/hotspot/src/os/linux/vm/os_linux.cpp +++ b/hotspot/src/os/linux/vm/os_linux.cpp @@ -368,13 +368,13 @@ void os::init_system_properties_values() { //        ... //        7: The default directories, normally /lib and /usr/lib. #if defined(AMD64) || defined(_LP64) && (defined(SPARC) || defined(PPC) || defined(S390)) -#define DEFAULT_LIBPATH "/usr/lib64:/lib64:/lib:/usr/lib" +#define DEFAULT_LIBPATH "" #else -#define DEFAULT_LIBPATH "/lib:/usr/lib" +#define DEFAULT_LIBPATH "" #endif // Base path of extensions installed on the system. -#define SYS_EXT_DIR     "/usr/java/packages" +#define SYS_EXT_DIR     "" #define EXTENSIONS_DIR  "/lib/ext" #define ENDORSED_DIR    "/lib/endorsed" @@ -437,13 +437,13 @@ void os::init_system_properties_values() { strlen(v) + 1 + sizeof(SYS_EXT_DIR) + sizeof("/lib/") + strlen(cpu_arch) + sizeof(DEFAULT_LIBPATH) + 1, mtInternal); -    sprintf(ld_library_path, "%s%s" SYS_EXT_DIR "/lib/%s:" DEFAULT_LIBPATH, v, v_colon, cpu_arch); +    sprintf(ld_library_path, "%s%s", v); Arguments::set_library_path(ld_library_path); FREE_C_HEAP_ARRAY(char, ld_library_path, mtInternal); } // Extensions directories. -  sprintf(buf, "%s" EXTENSIONS_DIR ":" SYS_EXT_DIR EXTENSIONS_DIR, Arguments::get_java_home()); +  sprintf(buf, "%s" EXTENSIONS_DIR, Arguments::get_java_home()); Arguments::set_ext_dirs(buf); // Endorsed standards default directory. </ins>

Related discussion:
text: Describe the bug I encountered this bug when trying to use that does FFI. The particular call in general was the equivalent dlopen on the libc library and resolving to the system one which would cause a SIGSEGV. Digging into the source some more, you discover that Java sets a default value for if it's not explicitly set. Adding system libraries (i.e. /usr/lib) breaks/invalidates the hermetic invariant needed by Nix. These library paths are also searched first before those set in the DTRUNPATH of the ELF header as documented. I suggest the OVERRIDELIBPATH is either set to empty string maybe or even the contents of the ELF RUNPATH header itself. To Reproduce I was using JRuby which makes it easy to reproduce by using a gem which ultimately calls the JNR FFI. (The following reproduction results in the SIGSEGGV) Expected behavior Expected behavior is for the FFI call to work! This can be resolved by setting to the correct lib. NOTE: I could not merely set LDLIBRARYPATH because that would apply to everything in my nix-shell. Furthermore, wrapping java is somewhat tedious, seemed pragmatic for now. Notify maintainers Metadata Maintainer information: All JDK derivations
If you are curious for the JNR call that loads the C library:
OVERRIDELIBPATH is not sufficient, because it still SYSEXTDIR/lib, which is somewhere in . We'll need a patch. This also means we might as well write C code to get the right rpath value, even when . Although less useful, I'd be ok with a patch that just makes it . At least that will give a somewhat useful error message instead of a crash. ~It seems like OVERRIDELIBPATH was designed for cases like ours. Setting it to a static rpath value is tricky because that way we're duplicating it in a way that can't be later. It a statically known value. So I'd go with the empty value.~
I'm hoping (haven't tested) that with an empty OVERRIDELIBPATH the DTRUNPATH at least will be searched for. Do you want to work on this change together ?