Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
Using the JNI with QT - Lib/DLLs are giving a file format error
Hi there, I am currently trying to use the JNI with QT, to allow me to run some Java function inside my C++ application. I have added the correct INCLUDEPATH to the JNI.h and JNI_md.h files which is:
INCLUDEPATH += "C:/Program Files/Java/jdk1.8.0_65/include/" INCLUDEPATH += "C:/Program Files/Java/jdk1.8.0_65/include/win32/"
I have also adds a LIBS flag to the .pro file to tell QT where the JNI dll is located which looks like the following:
LIBS += "C:/Program Files/Java/jre1.8.0_65/bin/server/jvm.dll"
However, once I attempt to build my program I get an error saying "file not recognized: File format not recognized" on the .DLL file. Has anyone else got the JNI to work with QT? Am I doing something wrong?
Hi, are you building a 64-bit Qt program? Otherwise, the error could be because mixup of 32-bit and the 64-bit jvm.dll.
I'm not sure, is there a way to check?
Sure (assuming you are using shadow builds) you can look at the directory name for your program's .exe file, something like "build-myprogram-Desktop_Qt_5_5_1..." it should say either 32bit or 64bit.
I had a look and I'm building a 32 bit application. I would imagine that the DLL is 32bit as well. Unless you know of a way to check?
Easiest is to check if you have a 32bit or 64bit installation of Java, open a CMD window and type:
"C:\Program Files\Java\jdk1.8.0_65\bin\java.exe" -version
You should see 3 lines, the last one tells if you have 32bit or 64bit Java.
It gave me this response: http://i.imgur.com/WDCfFhx.png
So I guess I do have the 64bit JNI? I'll have a look to see if there is a 32bit version. Or would it be easier to build my application as 64bit?
Thanks for your help.
Well 64-bit is the future :-) So I think try building your app as 64-bit.
However on Windows that requires you to have Visual Studio 2013 installed (there's no 64-bit option for the MinGW compiler :-(
Ahh OK that makes sense. I have Visual Studio 2013 installed, is there a step by step process to compile my QT application for 64bit?
It's pretty straightforward: first run Qt's MaintenanceTool.exe app to add 64-bit Visual Studio 2013.
Then to select 64-bit build for your project, easiest is to remove the file ending with "pro.user" (like myprogram.pro.user) and next time you start Qt Creator you should be able to select the 64-bits build.
OK so I haven't tried to build the 64bit application yet, but I did try to download and use a 32bit Java version. I updated the .pro file to use the new Include Paths and LIBS flag:
INCLUDEPATH += "C:/Program Files (x86)/Java/jdk1.8.0_74/include/" INCLUDEPATH += "C:/Program Files (x86)/Java/jdk1.8.0_74/include/win32/" LIBS += "C:/Program Files (x86)/Java/jre1.8.0_74/bin/client/jvm.dll"
The "file format not recognized" error seems to have disappeared (yay?) but now I get the following error:
undefined reference to `_imp__JNI_CreateJavaVM@12'
I assume I'm still doing something incorrectly? My guess is using the 64bit application will also produce this error?
I seen a few bits and pieces online about .Lib files and .a files, are they something I need?
Yeas you have now opened another nice can of worms. For starters you'll need a jvm.lib, here's an example Good luck!
Thanks for the link, it doesn't do anything differently from the way I have everything coded at the moment though. I have all the same (or similar) code to set up the JVM and call Java functions, but my project wing build because of that undefined reference error. It doesn't seem to mention anything about .lib/.a files either, do I just need to add the location of the JVM.lib to the libs flag in the .pro file? Or is there more to it?
Shouldn't this one
LIBS += "C:/Program Files (x86)/Java/jre1.8.0_74/bin/client/jvm.dll"
LIBS += -L"C:/Program Files (x86)/Java/jre1.8.0_74/bin/client" -ljvm"
But it probably will not work in any case because you use MinGW and JRE most probably another (VS?) compiler. On Windows you cannot mix compilers.
Aren't the -L flags only used in Linux systems? Or did I read that wrong?
OK so the problem might be the JVM.dll was compiled with a VS compiler and I'm trying to use it with the MinGW compiler? Is there a way to check what compiler the DLL was compiled with? Could I change the Compiler QT is using to the same one?
No they are not.
The first problem you have is that you are trying to link against a .dll which is wrong. You need the corresponding .lib file.
But first thing, do you need that for an Android application ?
Ok, I know the location of the .lib file, what should I do with it?
No this is just a regular windows application. There's a piece of code I'd like to use which is written in Java, I will perhaps look to convert it to C++ in the future but for now I'd just like to use the exisiting Java code.
Follow the example that @jsulm provided:
LIBS += -L"C:/Path/to/Java/libs/" -ljvm"
Nice one, thank you! Finally managed to get it working by only using these three lines in my .pro file
INCLUDEPATH += "C:/Program Files (x86)/Java/jdk1.8.0_74/include/" INCLUDEPATH += "C:/Program Files (x86)/Java/jdk1.8.0_74/include/win32/" LIBS += -L"C:/Program Files (x86)/Java/jdk1.8.0_74/lib/" -ljvm
and also by placing the JVM.dll where the .exe file is built by QT.
Unfortunately my program now crashes when it attempts to create a VM for Java and says
Error occurred during initialization of VM Unable to load native library: Can't find dependent libraries
But I guess that's a different problem!
It looks like the jvm DLL depends on at least one more DLL. You can use DependencyWalker to check which dependencies you have.
@jsulm I tried using the DependencyWalker on the JVM.dll, but it gave me some very strange results. I got a LOT of missing DLLs for things like API-MS-WIN-*.dll as you can see from the images here: http://imgur.com/a/h1CvW
There doesn't seem to be any other DLLs missing as far as I can tell.
Hi maybe not a missing DLL, but perhaps too many, it could be because you have more than one version of Java installed (32-bit and 64-bit).
Either uninstall all the Java versions you can find on your PC and reinstall just the one you need.
Or you can try to change the PATH env. variable so that the first entry in it points to your correct Java version, open a CMD window:
PATH = "C:\Program Files (x86)\Java\jre1.8.0_74\bin\client";%PATH%
and try to start your app from that CMD window.
I just tried doing that, however my program will not run outside of QT for some reason? If I click the run button in QT the program executes fine (but then gives me the JVM error as before), but if I run the program from the command line or by double clicking on it I get an error saying:
The procedure entry point __cxa_throw_bad_array_new_length could not be located in the dynamic link library D:\My Documents\Qt Projects\build-PROGRAM-Desktop_Qt_5_5_1_MinGW_32bit-Release\debug\Qt5Core.dll
I have also tried it with the release version of my program but I get the same error.
Hi I think that error occurs because you copied the wrong Qt5Core.dll (from Qt Creators' bin directory) instead of the one in C:\Qt\5.5\mingw492_32\bin. Instead of copying manually, you could try windeployqt on your .exe file.
@hskoglund I just deleted all the .dlls in my folder and copied
from the C:\Qt\5.5\mingw492_32\bin
into the folder where my .exe file is, unfortunately I still get the same entry point error.
Hmm, that error with "__cxa_throw_bad_array_new_length" is most likely due to a mixup of your mingw and Visual Studio 2013 installation flavors of Qt.
You can check what flavor that Qt5Cored.dll you copied has, by downloading and running Dependency Walker, open Qt5Cored.dll and see what dlls it needs. Maybe you need to reinstall Qt :-(
RBrNx277 last edited by RBrNx277
Managed to eventually get windeployqt to work, and that solved my entry point error so thank you! No idea why it wasn't accepting the DLLs that I had copied manually.
EDIT: I should add that windeployqt got rid of both the Entry Point error I had, along with the unable to find native library error. I have no idea how it fixed them both, perhaps it gave me a different JVM.dll.
hskoglund last edited by hskoglund
Excellent, so maybe now you can get back to hacking/testing some Java...