search

libgdx / packr

Packages your JAR, assets and a JVM for distribution on Windows, Linux and Mac OS X
Apache License 2.0
2.57k stars 171 forks source link

Can't run Java 8 on Windows 10 x64 without Windows SDK? #82

Closed TheLQ closed 7 years ago

TheLQ commented 8 years ago

I have a near vanilla Windows 10 VM that cannot run any of the executables with Java 8u111. Running with the console shows

Loading JVM runtime library ...
Error code [126]: The specified module could not be found.
Error: failed to load VM runtime library!
Press ENTER key to exit.

Things I've tried

The only thing that did work is installing the Windows SDK as specified in #49 . However I clearly can't install that on every users machine. What exactly is required to be installed on a vanilla Windows machine to run the executable?

Config below

{
    "platform": "windows64",
    "jdk": "/home/leon/jre-extract/java-1.8.0-openjdk-1.8.0.111-1.b15.ojdkbuild.windows.x86_64.zip",
    "executable": "brailleblaster-packr",
    "classpath": [
        "brailleblaster.jar"
    ],
    "mainclass": "org.brailleblaster.Main",
    "output": "out-packr-win"
}
code-disaster commented 8 years ago

Can you try running Dependency Walker on jre\bin\server\jvm.dll ? I wonder if it tells you which dependency is missing.

TheLQ commented 8 years ago

Lots of files are missing, see below. I just remade the VM as Java was installed on the old one so it represents a normal user's machine. Note both OpenJDK and Oracle JRE can run my app if called manually, it's only when using the executable that I have this problem

jvm.dll.openjdk.txt brailleblaster-packr.txt

code-disaster commented 8 years ago

Your log reveals msvcr100.dll is missing on the clean install. It works when running the JRE manually because this DLL is included in jre/bin. If you don't want users to install the VC runtime redistributables (the full Windows SDK shouldn't be needed), it may be sufficient to pick the DLL from jre/bin and put it right next to the packr executable.

kcpeppe commented 7 years ago

This is a crazy work-around. Is there any way to correct the path/ld_library_path so that the proper dll's are picked up? I'm concerned that this might cause some difficulties when distributing to other Window distro's.

code-disaster commented 7 years ago

Windows DLL dependency hell. At least msvcr100.dll is the only non-system DLL required, and it only depends on kernel32.dll by itself. Also I'm not sure if this is true for all JRE variants out there, though it seems to be the case for the Oracle and OpenJDK versions I looked at.

This is why you can't install almost any game on Windows without its installer sneaking in one of the VC runtime distributables.

One idea I had is to add a fallback, which, when detecting a DLL load error, tries to load msvcr100.dll first, and then retries to load jvm.dll. Another (brute-force) option would be to let packr just copy the DLL during build creation.

kcpeppe commented 7 years ago

Wow, you'd think that after more than 25 years this problem would be solved. Thanks for the quick support

code-disaster commented 7 years ago

I don't have a pristine Windows system to test with, so it'd be cool if one of you can try to replace your 32-bit or 64-bit executable with the ones found here:

https://github.com/code-disaster/packr/tree/%2382/src/main/resources

kcpeppe commented 7 years ago

My pristine install of 10 yields the following error message.

The program or feature "......\packr\output\myexec.exe" cannot start or run due to incompatibility with 64-bit versions of Windows. Please contact the software vendor to ask if a 64-bit Windows compatible version is available.

This wasn't a clean build in that I repacked my existing packr.jar replacing the 2 windows executables. I will leave this windows distro running if you'd like me to run any more tests.

code-disaster commented 7 years ago

If this is a 64-bit version you are building (so you bundle a 64-bit JRE too), you only need to copy/replace packr-windows-x64.exe. The 32-bit executable won't work here.

kcpeppe commented 7 years ago

I replaced both.

As a follow up, I've just cloned your repository, executed mvn clean package and then packaged my app. The run produced an error code of 126. failed to load VM runtime library.

code-disaster commented 7 years ago

Odd. Did you checkout my "#82" branch?

kcpeppe commented 7 years ago

My mistake, I built again master and not "#82" branch. I've corrected and your branch solves my problem. Test application runs as expected. We will get others to run tests on other Window distro's over the next few days and I'll report any problems back to here

code-disaster commented 7 years ago

Nice! Thanks a lot for testing.

fblampe commented 6 years ago

Hi,

currently I still have to move the msvcr.dll file next to the .exe file to get rid of the pop-up error message. Is that intended?

The program runs fine even with the error being shown, but it's confusing for users and having to copy the DLL manually (or even with a build script) after packr finishes building the packages is inconvenient.

It would be great if there was a nice and smooth way to do this...

dmvanderuit commented 2 years ago

Hi,

I just spent a day being frustrated over this issue. I successfully packaged a Java app for MacOS, but when I decided to try and make an executable for Windows (on my mac), I got the following issue:

image

For anyone else running into this issue; I accidentally bundled my $JAVA_HOME into the Windows-application, which, of course, is not something Windows can understand. The error message was valid, because there's no jvm.dll in the unix-version of the JVM.

TLDR: Make sure you reference the correct JDK for the OS you're building for in the --jdk-option when running packr.

kidmtt94 commented 1 year ago

Windows DLL dependency hell. At least msvcr100.dll is the only non-system DLL required, and it only depends on kernel32.dll by itself. Also I'm not sure if this is true for all JRE variants out there, though it seems to be the case for the Oracle and OpenJDK versions I looked at.

This is why you can't install almost any game on Windows without its installer sneaking in one of the VC runtime distributables.

One idea I had is to add a fallback, which, when detecting a DLL load error, tries to load msvcr100.dll first, and then retries to load jvm.dll. Another (brute-force) option would be to let packr just copy the DLL during build creation.

Hi sir, Does this still work in latest JRE 8 U351 ? The file msvcr100.dll in JRE 8 U351 doesn't exist. Only msvcr140.dll, msvcr140_1.dll, msvcr140_2.dll exist. Should I try to load all of them first ?