Failed to launch JVM

[pradeepsimba]

Failed to launch JVM

[lacasseio]

What most likely is missing is the runtime shared library for QT? There are several ways to solve this depending on how you end up running your application or executing code inside your library.

[lacasseio]

If you have a sample, we can look into it to make it work.

[lacasseio]

I converted the issue to a discussion that better suits the request. Feel free to provide additional information so I can provide more help.

[lacasseio]

Thanks a lot for the detailed explanation. 👍

I'm still holding my original assessment which is the lack of the QT shared library in your PATH. By default QT links against the shared library (due to licensing) which means on your host system, you will also need the QT shared libraries. You need to make sure those shared libraries are accessible via your PATH environment variable. When Windows loads the dependent libraries to your JNI shared library (e.g. QT shared libraries), it will look into the PATH environment variable. Note the java.library.path is only for the JVM to find the shared library by the JNI protocol.

In GitHub Action, you use jurplel/install-qt-action action to install the QT library which will configure the PATH for you by default (see set-env input). On your local machine you will have to do something like set PATH=%PATH%;<path-to-qt-bin> in the command prompt that you invoke Gradle. The set command will only change the PATH in the command prompt (not the system). To get the same result in IntelliJ, you either need to use the same command prompt you configured the PATH to launch the IntelliJ (to propagate the modified PATH or modify your run configuration use to execute your commands (under the Run menu).

I hope that helps.

[pradeepsimba]

I can't understant. Please, can you give more information ?

[lacasseio]

As much as I want to help you, what you are asking is a bit outside the scope of Nokee. The build scripts are essentially correct for building the shared library. As explained previously, the issue is the environment where GitHub actions have the QT binaries in the PATH while the local machine, most likely, does not. The last linked GitHub actions output shows the same local result because the QT installation step is missing, hence confirming the issue is in relation to the missing QT binaries. There is no clean way to magically pull the QT binaries through normal dependency resolution in Gradle. As part of the Nokee project, we are working on that but we don't have anything that could help right now.

Supporting JPackage is a bit outside the scope of Nokee. We offer consulting/development work as a paid service and I would gladly take all the time required to make you successful. Without that, I can try to guide you to the solution but I can't write the solution for you.

That being said, I looked a bit at the documentation of JPackage and it seems what you would be looking for is answered in this question on stackoverflow. To automate this in Gradle, you would most likely need two tasks (or one custom task that does both): 1) sync all the files to create the input directory for the JPackage command and 2) exec the JPackage command. A POC of that process would most likely look like this:

def syncTask = tasks.register('syncJPackage', Sync) {
    from(file("${project(":hello").buildDir}/lib/main/debug"))
    from(tasks.named('jar'))
    from(file('<path/to/qt/bin>')
    destinationDir = temporaryDir
}

tasks.register('execJPackage', Exec) {
    dependsOn syncTask
    commandLine 'jpackage', '--input', "$buildDir/tmp/${syncTask.name}", '--java-options', '-Djava.library.path=$APPDIR', '--main-jar', '<name of the jar in input folder>', '--main-class', '<name of main class>', ...
}

Basically, what we are doing here is to create a folder with everything the application needs: the JNI shared library, the application JAR and all the QT binaries. On Windows, the system should look for the dependent DLL in the directory where the parent shared library is loaded, in this case, the same directory where all the QT binaries are copied. In theory, it should all work. You will need to adjust a couple of parameters but that base idea is correct.

If you want your test task to work properly, you will need to export a PATH environment that contains the QT binaries. It may work by just adding them to -Djava.library.path parameters but I'm unsure at this time. You would need to give it a try.

[pradeepsimba]

<path/to/qt/bin>

def syncTask = tasks.register('syncJPackage', Sync) {
    from(file("${project(":hello").buildDir}/lib/main/debug"))
    from(tasks.named('jar'))
    from(file('<path/to/qt/bin>') // path to qt bin folder
    destinationDir = temporaryDir
}

QT bin folder path

**size of that folder **

I have one doubt. If I copy the bin folder of QT the jpackage's size will increase more then 250MB .

If I copy and past the qt bin folder in to here then this project will work ?

[lacasseio]

Copying the QT bin folder is the lazy approach meaning you will basically include everything QT offers including tools which are not exactly what you need but it's the easiest solution to validate your problem is fixed. I don't think copying the QT bin in lib folder will work because of the shared library load order (and process). I believe the order you should expect is describe here for Windows.

In your case, you use QString which most likely means you could be found by just copying Qt5Core.dll (if my memory is correct, where QString is in QT core). Note the Qt5Cored.dll is the debug version and you really only need the release version (without d suffix).

I would first validate the 250Mb package work as expected (to ensure there isn't another issue we missed) before cherry-picking the DLLs. You may want to read this section of the QT Windows deployment. The tool dependency walker can help figure out any additional DLL that you need to package. As I mentioned previously, generally on the development machine, you would install those dependencies that would be available via the PATH environment variable. When deploying, you can either package them inside your distribution (when the license allows it) or request the user to install the redistribution package (ex. like the Visual C++ Redistributable).