Add LD_LIBRARY_PATH to JavaInstallerMixin #11667
Conversation
| @@ -56,6 +56,7 @@ def get_java_env_vars(self, path: str = None) -> dict[str, str]: | |||
|
|
|||
| return { | |||
| "JAVA_HOME": java_home, | |||
| "LD_LIBRARY_PATH": f"{java_home}/lib:{java_home}/lib/server", | |||
There was a problem hiding this comment.
This would effectively overwrite an existing LD_LIBRARY_PATH wherever we use the Java mixin / this function. I think this should be handled the same way as for the path.
There was a problem hiding this comment.
@alexrashed but shouldn't this be treated more like JAVA_HOME and localised to the Java environment to be used? An invalid exisiting LD_LIBRARY_PATH value might potentially poison the environment.
There was a problem hiding this comment.
Sure, there definitely shouldn't be a faulty LD_LIBRARY_PATH, but couldn't it be necessary to have the shared libraries of Java as well as other libraries in the LD_LIBRARY_PATH?
For example in OpenSeach we add custom libraries for KNN to the LD_LIBRARY_PATH here:
I know that for opensearch we use the Java runtime from the package, but that would be an example where we would have to have multiple paths on the LD_LIBRARY_PATH.
Background
https://github.com/localstack/localstack-ext/pull/3419 removed the global default JRE installation. This caused certain tests to start failing for aarch64.
Changes
This PR sets the
LD_LIBRARY_PATHenv var with Java libs and adds it to theJavaInstallerMixin.Generally it is advisable to set
java.library.pathon the JVM's command line. But this approach should be a global fix. Besides this used to be set in the Dockerfile in the era of global JRE.Tests
This was detected with following failure:
Tested passing with following CI run:
https://github.com/localstack/localstack-ext/actions/runs/11272853744/job/31350949612 🟢