-1

I am running a program written with Java that is made by the work I work with. It depends on libjpeg-turbo (version 1.5.1 vc64) While running it from the Windows command line (CMD.exe), a Java exception occurred starting with this error message:

Exception in thread "pool-1-thread-1" java.lang.UnsatisfiedLinkError: Expecting an absolute path of the library: /opt/libjpeg-turbo/lib32/libturbojpeg.so

I am running it from Windows 10, but it seems to looking for it libjpeg-turbo in a Linux location. I think it is assuming the OS is a Linux system, instead of Windows. I have gotten it to work on another Windows 10 computer just fine. I have WSL enabled on both computers, using the Ubuntu distro. Maybe that has something to do with it?

Any ideas as of what could be causing this? I am working with the developer on this issue, but I figured it wouldn't hurt to through this question out here to see if we can get some outside help on the issue.

Other information: (let me know if more is needed)

  • Windows 10, 64-bit
  • WSL, Ubuntu distro
  • Java 8 (latest as of 4-21-2019)
  • libjpeg-turbo 1.5.1-vc64, installed on Windows 10, not through WSL
Improve this question
4
  • Just to be clear, are you running the Java program from a Windows command line (cmd.exe or powershell.exe), a Linux command line (bash.exe, wsl.exe, <distroname>.exe), or from some weird other thing like Git Bash (which is bash.exe but not the WSL one; it's technically a Win32 program)? If you try running your java command from another command line, such as Powershell, does it behave differently?
    – CBHacking
    Apr 21, 2019 at 19:53
  • @CBHacking I am running it from a Windows command line. I will have to try it in Powershell to see if it is different
    – Christian Sirolli
    Apr 21, 2019 at 20:11
  • I wish someone would explain why they downvoted
    – Christian Sirolli
    Apr 21, 2019 at 20:13
  • @CBHacking it performs the same way with Powershell.
    – Christian Sirolli
    Apr 21, 2019 at 20:23

2 Answers 2

Reset to default
0

You should ask yourself why the program runs on one Windows machine and not on the other. Something must be different. What happens if you copy the program from the working machine to the other? Maybe you need to copy any libjpeg-turbo files to a special location?

It seems libjpeg-turbo is not found by the program and tries to load it from /opt/libjpeg-turbo/lib32/libturbojpeg.so instead.

Set the PATH variable to the correct location PATH=C:\path-to-libjpeg-turbo;%PATH% or use property -Djava.library.path=C:\path-to-libjpeg-turbo when the program is started.

Improve this answer
4
  • Sadly, adding it as part of the path, both as part of the path variable and using the D parameter didn't work. I am still looking into what all is different about the two setups
    – Christian Sirolli
    Apr 21, 2019 at 20:37
  • Copy the working version and try to start it. If it fails, check java -version and compare echo %PATH% and echo %JAVA_HOME% in cmd. Then compare the installation location and the files of libjpeg-turbo.
    – Freddy
    Apr 21, 2019 at 20:49
  • what is %JAVA_HOME%? I do not have that on either.
    – Christian Sirolli
    Apr 21, 2019 at 21:25
  • @ChristianSirolli It's java's home directory. It seems you only have the JRE installed and not the SDK. Should be okay if the variable is not set on both systems.
    – Freddy
    Apr 21, 2019 at 21:33
0

Since you have two computers and it works on one but not the other, you can do some comparison to see what is different between them. A few likely candidates, in approximate order of how I would check them:

  1. Is the program the same on both machines? While Java software is intended to be portable, sometimes people build different versions for different platforms, and you might have accidentally downloads a Linux on one machine. You could hash the two JAR files to compare them.
  2. Is the program being invoked the same way on both machines? If you're running a script or executable (rather than just invoking java.exe or javaw.exe yourself), is the invoker the same on both machines? Those Java launch wrappers are very commonly platform-specific, and depending on what is installed on your machine it might run one written for Linux far enough to get the failure you're seeing.
  3. Is the Java runtime the same on both machines? While this shouldn't matter in this particular case, the JRE can be a temperamental beast and you should verify that the exact same version (including 32-bit vs. 64-bit) is installed in both places.
  4. Is there an environment variable causing confusion on one machine? While the program should be asking the Java runtime what OS it's on, rather than checking things like environment variables to try and figure it out, sometimes people don't do things the right way, and sometimes an environment variable has an unexpected effect.
  5. Is the install location the same (or close enough) between machines? Things like one of them having a space in the path and the other not could trip some common bugs.
  6. What libraries is the working machine's copy loading, and are those libraries in the same place on the not-working machine? You can use Windows' built-in Resource Monitor (or some other tools) to see what libraries a program has loaded.
  7. What system calls does each program make, and how do they differ between the working and non-working systems? You can use Process Monitor from the Sysinternals suite of tools (owned by Microsoft and available free online) to trace the program on each system; at some point they will presumably diverge (either in syscall parameters or in responses) and the position and nature of that divergence will probably provide enough info to figure out what the difference is or at least where to look next (and if not, ask about it here!).
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .