1

I have a Java app using a C file via JNI dependant on a C library (FFMPEG). I have compiled two versions of these C libraries and by checking with the Dependency Walker the output is indeed 32 and 64 bit. I have no problem building and running the 64 bit app with Eclipse 64 bits, 64 bit JRE, compiling my JNI C class with Mingw64. I am trying to do the same on the 32-bit Eclipse with 32-bit JRE and having some issues on System.loadLibrary().

ERROR: java.lang.UnsatisfiedLinkError: C:\Dev\wks\HelloFfmpeg\VideoProcessor\bin\helloffmpeg.dll: Can't find dependent libraries

Here are the checks I have done

  • Eclipse is 32-bit
  • In this instance of Eclipse I have only 1 JRE setup, the 32-bit one, and this is the one used to start the app in my Run Configuration
  • In C/C++ build I have set MINGW_HOME to point to Mingw32 which has 32-bit gcc
  • I have copied all the required DLLs (the 32-bit version of each and everyone that i use to run the 64-bit version of the app) in the same folder as the helloffmpeg.dll in the BIN folder

Dependency Walker tells me this:

  • C:\Dev\wks\HelloFfmpeg\VideoProcessor\bin\helloffmpeg.dll is a 32-bit DLL
  • The 32-bit ffmpeg DLLs I use are indeed 32-bit and found when loading helloffmpeg.dll

Now there are two things that I am not too sure about:

  • When I build the 32-bit version I get this in Eclipse CDT output, the rest looks fine

    Info: Configuration "Default" uses tool-chain "MinGW GCC" that is unsupported on this system, attempting to build anyway.

  • In Dependency Walker, some system DLLs found are 64-bit version, for example enter image description here I am not sure about these they seem to be system libraries, and one is MinGW library. If I distribute my 32-bit app do I need to include some MinGW dlls? This doesn't seem right. Out of the four errors at the bottom the ones that don't show up with the 64-bit version are these two

    Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module.

    Error: Modules with different CPU types were found.

I understand the second as per above but I am not sure to understand the first one.

UPDATE

I followed the advice below and opened the 32-bit DLL with 32-bit dependency walker, and making sure my PATH now points to mingw32/bin and not mingw64/bin. The result is much cleaner and the correct version of LIBWINPTHREAD-1 can be found:

enter image description here

There is no other error when using DWW. However when I start my program I still get 

ERROR: java.lang.UnsatisfiedLinkError: [blabla].dll: Can't find dependent libraries

Is there any way to check on which dependent library the JNI loader fails?

UPDATE2

I resolved the problem in update1, I also had a PATH override in my eclipse launch configuration... I can now successfully start the program and load the JNI library and its dependency. However I still have one issue with the 32-bit library, I get an UnsatisfiedLinkError when trying to call the first JNI method, saying that it doesn't exist. I noticed in DWW that the method names have @8 or @16 after them, I reckon this is causing the problem as the 64-bit DLL doesn't have this

32-bit DLL:

enter image description here

64-bit DLL:

enter image description here

UPDATE 3

The @ sign at the end of 32-bit methods is resolved using the answer from kool on this thread.

Community
  • 1
  • 1
tishu
  • 998
  • 15
  • 29
  • If Dependency Walker finds 64 bit dependencies you're probably using a 64 bit dependency walker that looks in System32 for system DLLs. Use the 32 bit DW, this will look in SysWOW64 where the 32 bit DLLs are. (Will not solve your problem but misleading information will be out of the way) – user2543253 Jul 15 '16 at 15:13
  • Looking closer at your screenshot, the libwinpthread-1 might be the problem. Is its directory in your PATH? Putting dependency DLLs in the directory where the "main" DLL is in will not automatically pick them up (only when they're in the current working directory). Maybe your 64 bit program gets its DLLs from the PATH and so might do your 32 bit program and get the wrong DLLs this way. (Just guessing) – user2543253 Jul 15 '16 at 15:21

0 Answers0