Open ctrueden opened 3 months ago
macOS dyld
documents that it only looks at the env vars at process launch (not sure about Linux ld.so
). So it would probably be useful to be able to relaunch with an altered environment (especially for ImageJ plugins that expect the current environment). On the other hand, if I were shipping an app with a fixed set of JNI libraries, I would probably want to have total control over all these paths (and may not necessarily want java.library.path
to equal LD_LIBRARY_PATH
; neither is necessary if the Java class knows where to find the JNI library and the JNI library contains the paths of its dependencies). Also because these paths can have security implications.
This issue has been mentioned on Image.sc Forum. There might be relevant details there:
https://forum.image.sc/t/jaunch-a-new-java-launcher-test-fiji-with-java-21/92058/1
The ImageJ Launcher builds up a
java_library_path
with (on Linux)LD_LIBRARY_PATH
or (on macOS)DYLD_LIBRARY_PATH
, and thenlib/<platform>
.${app-dir}/lib
that contain at least one native library for that platform. (It even checks the contents of every candidate to make sure it really is a native library structurally...)java_library_path
toPATH
.execvp
to re-execute the native launcher when the originalLD_LIBRARY_PATH
/DYLD_LIBRARY_PATH
does not match the built-up one.-Djava.library.path=${java-library-path}
to the JVM.Should Jaunch do any/all of this? It hinges on whether the following comment is still true: "Unfortunately,
ld.so
only looks atLD_LIBRARY_PATH
at startup, so we have to reexec after setting that variable."From the ImageJ Launcher source code: