java.lang.UnsatisfiedLinkError: jpeg.dll: Can't find dependent libraries
dmitrysm2000 opened this issue · comments
The following error is thrown in Tomcat application using OpenJDK 8 ZIP distribution when no MSI is installed on the same server.
java.lang.UnsatisfiedLinkError: ...\java-1.8.0-openjdk-1.8.0.232-1\jre\bin\jpeg.dll: Can't find dependent libraries
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1934)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1838)
at java.lang.Runtime.loadLibrary0(Runtime.java:870)
at java.lang.System.loadLibrary(System.java:1122)
at com.sun.imageio.plugins.jpeg.JPEGImageWriter$1.run(JPEGImageWriter.java:180)
at com.sun.imageio.plugins.jpeg.JPEGImageWriter$1.run(JPEGImageWriter.java:178)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.imageio.plugins.jpeg.JPEGImageWriter.(JPEGImageWriter.java:177)
at com.sun.imageio.plugins.jpeg.JPEGImageWriterSpi.createWriterInstance(JPEGImageWriterSpi.java:96)
at javax.imageio.spi.ImageWriterSpi.createWriterInstance(ImageWriterSpi.java:351)
at javax.imageio.ImageIO$ImageWriterIterator.next(ImageIO.java:843)
at javax.imageio.ImageIO$ImageWriterIterator.next(ImageIO.java:827)
This happens with OpenJDK java-1.8.0-openjdk-1.8.0.212-1 and java-1.8.0-openjdk-1.8.0.232-1, and does not with java-1.8.0-openjdk-1.8.0.201-1.
Happens only when executed from Tomcat (as a Windows service or console application) and does not happen in a simple Java main with the same code.
When OpenJDK MSI distribution is installed on the same machine (even if it is not used by the Tomcat installation, tried with java-1.8.0-openjdk-1.8.0.201-1) - everything works.
Thanks for the report! This issue is very similar to #34. There is an ongoing work to link jpeg (and also gif and png) dependency libraries differently to drop additional shared libs (and basically get the behaviour all other jdk-windows builds have).
Some explanation for current behaviour: one of the initial requirements for these builds was to use dependency libraries the same way they are used on RHEL/CentOS. So these libraries (zlib, libjpeg-turbo and some others) were built for windows as shared libs, linked dynamically to jdk libs and included with jdk (inside bin and jre/bin dirs). That provided some safety (separate C heap, if something is wrong inside the lib - crash logs will point directly to problematic DLL) and replicated Linux behaviour closely. This also worked without problems with standard launchers (java.exe, javaw.exe) and passed all the testing. However problem arose with custom launchers (procrun/prunsrv that is used by Tomcat, details in #34), that loads JVM through JNI invocation API and doesn't expect any additional shared libraries.
Going to implement the fix to this (drop additional shared libs) and publish updated builds in 1-2 weeks.
Workaround for the current version - add <jdk>/bin or <jdk>/jre/bin to the PATH environment variable (so all shared libs are found from there even if run from procrun).
Thank you for the information. The suggested workaround worked for us.
Updated release is published now and this problem should not happen with it. Closing as "fixed", please re-open if problem persists.