Library path in LWJGL 3

Started by Finalspace, November 16, 2014, 09:03:20

Previous topic - Next topic

Finalspace

Hi there,

in the past for LWJGL 2, i used System.setProperty("lwjgl.library.path", pathToLWJGLNativeOS) to set the library path for the natives before i execute the first LWJGL function.

Now, it seems that LWJGL 3 uses java library path instead. Of course passing parameters as VM arguments (-Djava.library.path) works, but i like the runtime way... is there a plan to support back the "lwjgl.library.path" ?

And much more important, why do i need to call this before i do any glfw stuff:

Sys.getVersion();

If i do not call this, i get an unsatisfied link error even though i have set up the library path correctly.... not the end of the world, but why?

spasi

Hello,

Quote from: Finalspace on November 16, 2014, 09:03:20in the past for LWJGL 2, i used System.setProperty("lwjgl.library.path", pathToLWJGLNativeOS) to set the library path for the natives before i execute the first LWJGL function.

Now, it seems that LWJGL 3 uses java library path instead. Of course passing parameters as VM arguments (-Djava.library.path) works, but i like the runtime way... is there a plan to support back the "lwjgl.library.path" ?

You probably mean "org.lwjgl.librarypath". This is still supported. There will also soon be another improvement to the loading process, to ensure LWJGL 3 is as easy to use as 2.

Quote from: Finalspace on November 16, 2014, 09:03:20why do i need to call this before i do any glfw stuff:

Sys.getVersion();

If i do not call this, i get an unsatisfied link error even though i have set up the library path correctly.... not the end of the world, but why?

Please keep an eye to this issue.

Sys.getVersion() is not needed of course, but it has the side-effect of initializing the Sys class, which is necessary for the native LWJGL library to load. This will be done automatically in the near future.

buesthe

I am also struggeling loading the library when setting org.lwjgl.librarypath in runtime. If I set it as a VM argument, it works, but I would like to add this runtime!
Also I am not using the jars containing the .dlls. I have them in a common folder in my project.

The following VM arguments are set:
-Dorg.lwjgl.util.Debug=true
-Dorg.lwjgl.util.DebugLoader=true

System.setProperty("org.lwjgl.librarypath", myNativeLibPath);
long device = ALC10.alcOpenDevice((ByteBuffer)null);

This prints:

[LWJGL] Version: 3.3.1 build 7
[LWJGL]     OS: Windows 10 v10.0
[LWJGL]    JRE: Windows amd64 17.0.5
[LWJGL]    JVM: OpenJDK 64-Bit Server VM v17.0.5+8-LTS by Azul Systems, Inc.
[LWJGL] Loading JNI library: lwjgl
[LWJGL]    Module: org.lwjgl
[LWJGL]    windows/x64/org/lwjgl/lwjgl.dll not found in java.library.path= [long list of paths]
[LWJGL]    lwjgl.dll not found in java.library.path
[LWJGL] Failed to load a library. Possible solutions:
   a) Add the directory that contains the shared library to -Djava.library.path or -Dorg.lwjgl.librarypath.
   b) Add the JAR that contains the shared library to the classpath.
WARNING     | Problem in source 'SoundDevice_method': Failed to locate library: lwjgl.dll


If I add the VM argument:
-Dorg.lwjgl.librarypath=[my native lib path]

The loading works fine and I get this printout:
[LWJGL] Version: 3.3.1 build 7
[LWJGL]     OS: Windows 10 v10.0
[LWJGL]    JRE: Windows amd64 17.0.5
[LWJGL]    JVM: OpenJDK 64-Bit Server VM v17.0.5+8-LTS by Azul Systems, Inc.
[LWJGL] Loading JNI library: lwjgl
[LWJGL]    Module: org.lwjgl
[LWJGL]    Loaded from org.lwjgl.librarypath: [my native lib path]\lwjgl.dll
[LWJGL] Loading library: OpenAL
[LWJGL]    Module: org.lwjgl.openal
[LWJGL]    Loaded from org.lwjgl.librarypath: [my native lib path]\OpenAL.dll
[LWJGL] Java 10 multiplyHigh enabled
[LWJGL] Java 9 check intrinsics enabled


spasi

I cannot reproduce this, setting the property at runtime works for me. Could you prepare an MCVE please?

buesthe

Quote from: spasi on December 20, 2022, 16:13:57
I cannot reproduce this, setting the property at runtime works for me. Could you prepare an MCVE please?
I have tried to reproduce the error in a MCVE but there it works!  :o
My system has a complicated class loader structure so it might have something to do with that.
Therefore I tried to use a URLClassLoader in my MCVE and that also works fine.

When setting the property runtime at an earlier stage in my code, before the .newInstance() call on the Class object, it works...! I will have to scratch my head some more to make sense of this.

For now, it looks like the problem is not in LWJGL