search

ibmruntimes / Semeru-Runtimes

Issue repo for all things IBM Semeru Runtimes
14 stars 4 forks source link

File not found `libjawt.dylib` #95

Open jredfox opened 1 month ago

jredfox commented 1 month ago 
java.lang.reflect.InvocationTargetException
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:503)
    at net.minecraft.launchwrapper.Launch.launch(Launch.java:57)
    at net.minecraft.launchwrapper.Launch.main(Launch.java:18)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:503)
    at org.multimc.onesix.OneSixLauncher.launchWithMainClass(OneSixLauncher.java:243)
    at org.multimc.onesix.OneSixLauncher.launch(OneSixLauncher.java:278)
    at org.multimc.EntryPoint.listen(EntryPoint.java:143)
    at org.multimc.EntryPoint.main(EntryPoint.java:34)
Caused by: java.lang.UnsatisfiedLinkError: lwjgl (dlopen(/Users/jredfox/Desktop/MultiMC.app/Data/instances/1.6.1/natives/liblwjgl.dylib, 0x0001): Library not loaded: '@rpath/libjawt.dylib'   Referenced from: '/Users/jredfox/Desktop/MultiMC.app/Data/instances/1.6.1/natives/liblwjgl.dylib'   Reason: tried: '/Library/Java/JavaVirtualMachines/ibm-semeru-open-8.jdk/Contents/Home/jre/lib/default/libjawt.dylib' (no such file), '/Library/Java/JavaVirtualMachines/ibm-semeru-open-8.jdk/Contents/Home/jre/bin/./libjawt.dylib' (no such file), '/usr/lib/libjawt.dylib' )
    at java.lang.ClassLoader.loadLibraryWithPath(ClassLoader.java:1473)
    at java.lang.ClassLoader.loadLibraryWithClassLoader(ClassLoader.java:1424)
    at java.lang.System.loadLibrary(System.java:621)
    at org.lwjgl.Sys$1.run(Sys.java:72)
    at java.security.AccessController.doPrivileged(AccessController.java:690)
    at org.lwjgl.Sys.doLoadLibrary(Sys.java:66)
    at org.lwjgl.Sys.loadLibrary(Sys.java:96)
    at org.lwjgl.Sys.<clinit>(Sys.java:117)
    at net.minecraft.client.Minecraft.func_71386_F(Minecraft.java:2430)
    at net.minecraft.client.main.Main.main(SourceFile:37)
    ... 14 more

Issue: your missing critical AWT libraries and possibly more native libraries on Mac intel x64

Steps to reproduce:

pshipton commented 1 month ago

Reason: tried: '/Library/Java/JavaVirtualMachines/ibm-semeru-open-8.jdk/Contents/Home/jre/lib/default/libjawt.dylib' (no such file), '/Library/Java/JavaVirtualMachines/ibm-semeru-open-8.jdk/Contents/Home/jre/bin/./libjawt.dylib' (no such file), '/usr/lib/libjawt.dylib' )

The library is there in Contents/Home/jre/lib. It looked in jre/lib/default and jre/bin, but these are not the correct places. The OpenJDK build from Adoptium has libjawt.dylib in the same place as Semeru. I don't think the failure to find the library is a fault of Semeru.

jredfox commented 1 month ago

failure

I set the path directly to /Library/Java/JavaVirtualMachines/ibm-semeru-open-8.jdk/Contents/Home/jre/java or something like that so the path should find the library if it exists which it does not. It's only using IBM distro of java. Every single other java distro works except IBM on mac. On windows there is no issue with IBM distro of java. So the only reason why it couldn't find it is because it doesn't exist in the java executable code that it's trying to link to. Issue is not on adoptium's fault as that distro was never called only IBM was called. Also note: IBM java distro was not the latest installed and if it only occurs when this is the case that would mean it's grabbing the wrong natives to begin with and always using some weird natives that are not part of the install always unless IBM is the only one installed and only IBM JDK 8

pshipton commented 1 month ago

Did you try setting the path to /Library/Java/JavaVirtualMachines/ibm-semeru-open-8.jdk/Contents/Home/jre/lib?

jredfox commented 1 month ago

even if that were the case JDK is defined as java bundled with compile time dependencies thus it should work regardless of jdk or jre folder and would be a bug especially since one would not be able to develop a java application on this distro

pshipton commented 1 month ago

Perhaps there is a bug in Semeru but atm I don't know what that might be. The libjawt.dylib library is included in the right place. The error message indicates it didn't look in that place. Afaik the lwjgl library might have a problem, not setting up the correct place to look when running with Semeru.

jredfox commented 1 month ago

Perhaps there is a bug in Semeru but atm I don't know what that might be. The libjawt.dylib library is included in the right place. The error message indicates it didn't look in that place. Afaik the lwjgl library might have a problem, not setting up the correct place to look when running with Semeru.

I verified it happened in both directories and wasn't multimc specific same issue occured on technic and even straight from Terminal. This is a bug with either the PKG installer or Semeru itself on macOS intel x64

mstoodle commented 1 month ago

I agree with everything Peter says above: it does appear that the path containing libjawt.dylib isn't being searched and that should be the same path for both Eclipse Temurin and Semeru Runtimes. So it's really strange to read "Every single other java distro works except IBM on mac". Assuming the configuration is the same, Temurin and Semeru put the same library in the same place. I'll also point out, as Peter did, that the code that is trying to load libjawt.dylib is native code from the LWJGL project, and based on the stack trace, it's the older v2 of LWJGL (looks to be about 8 years old based on its GitHub repo (see https://github.com/LWJGL/lwjgl ). @jredfox can Minecraft be configured to use LWJGL3, I wonder? If so, then trying it out with v3 might help to get you going (I noticed that native library loading implementation seems to be significantly different in v3 versus v2).

Just for kicks, I wrote a simple testcase that just loads libjawt.dylib and ran into a problem that I've documented in #96. It's possible @jredfox will hit that problem once this issue is resolved.

It might also be helpful to collect the output when running with these environment variables set: .

Note copious output will be produced documenting all libraries being loaded, but for my little testcase in #96, I saw:

dyld[17188]: <28019B95-84B5-3A7B-8AE1-1DCF0677FCA5> /Library/Java/JavaVirtualMachines/ibm-semeru-open-8.jdk/Contents/Home/jre/lib/libjawt.dylib

I don't think we'll get that output in this case (because the library can't be found!), but perhaps we'll see something else in the output that will help us figure out what's happening, since there should be other libraries loaded by the JVM from the same jre/lib directory before it attempts to load libjawt.dylib from there (for example, libjava.dylib, libverify.dylib, libzip.dylib, ...).