UnsatisfiedLinkError with jzy3d builds only

[Sailsman63]

(Possibly related to #21 )

Arch Linux on amd64 Both openJDK and Temurin builds for JDK11 and JDK17 Both rc-20210111 and rc4 builds of jogl

When using artifacts from the jzy3d repository, I consistently get java.lang.UnsatisfiedLinkError: Can't load library: /mnt/develop/Shared/Source/ArtOfIllusion/natives/linux-amd64/libgluegen_rt.so

Note: the path returned is consistently ${user.dir}/natives/linux-amd64/libgluegen_rt.so no matter where I run the launch command. That is, it's looking under the directory where I'm running my shell.

Persists whether I leave the downloaded natives .jar named as-is, or rename to gluegen-rt-natives-linux-amd64 (without the version coding)

gluegen-rt.jar and jogl-all.jar are on the classpath, but the native jars are not. (They are in the same directory) Classpath is specified in the application main jar.

This is specific to the jzy3d artifacts. If I use the version directly downloaded from https://jogamp.org/deployment/archive/rc/v2.4.0-rc-20210111/jar/ , it loads and runs properly.

[jzy3d]

I have updated https://github.com/jzy3d/jogl/issues/21 since a solution was found. Not sure it relates to what you encounter but it may help?

[Sailsman63]

Thanks for the update. I've confirmed that this is not the same as #21.

• They apparently had permissions issues with part of their JDK installation, which affected all builds of jogamp. I'm seeing it only with the jzy3d builds
• I did double-check the permissions for the files as deployed by my build-script. Full 777 across the board, no matter which version I'm using.

What information might help track this down? I was really hoping to use the rc4 build for M1 support.

[jzy3d]

Maybe you can start by defining the env var -Djogamp.debug.IOUtil, it will print debug information on what's happening before reaching this UnsastisfiedLinkError. Could you copy paste the result here?

You may check the discussion we had on JOGL forum to get ideas on how we tried resolving #21. Starting from there I dived in JOGL source code trying to understand what's under the hood... let's see if it helps :)

[Sailsman63]

I've run this both from my normal working directory, and from the actual application directory. Both output the same (modulo some differences in the runtimes reported, which I'd assume are irrelevant)

IOUtil.getTempRoot(): tempX1 </tmp>, used true
IOUtil.getTempRoot(): tempX3 <null>, used false
IOUtil.getTempRoot(): tempX4 </home/sailsman63>, used true
IOUtil.getTempRoot(): tempX2 </home/sailsman63/.cache>, used true
IOUtil.testDirExec(): test-exe </tmp/jogamp_exe_tst16314779898710766688.sh>, existingFile false, isNioExec true, returned 0
IOUtil.testDirExec(): abs-path </tmp>: res 1 -> true
IOUtil.testDirExec(): total 17ms, create 0ms, fill 0ms, execute 17ms
IOUtil.testDirImpl(tempX1): </tmp>, create true, exec true: true
IOUtil.testDirExec(): test-exe </tmp/jogamp_0000/jogamp_exe_tst6632756178441196137.sh>, existingFile false, isNioExec true, returned 0
IOUtil.testDirExec(): abs-path </tmp/jogamp_0000>: res 1 -> true
IOUtil.testDirExec(): total 3ms, create 1ms, fill 0ms, execute 2ms
IOUtil.testDirImpl(tempX1): </tmp/jogamp_0000>, create true, exec true: true
IOUtil.getTempRoot(): temp dirs: exec: /tmp/jogamp_0000, noexec: /tmp/jogamp_0000
IOUtil.testDirImpl(testDir): </tmp/jogamp_0000/file_cache>, create true, exec false: true

The actual UnsatisfiedLinkErrors, on the other hand, do vary:

Error creating GLCanvasDrawer: java.lang.UnsatisfiedLinkError: Can't load library: /mnt/develop/Shared/Source/ArtOfIllusion/natives/linux-amd64/libgluegen_rt.so

When I attempt to launch from the working directory (/mnt/develop/Shared/Source/ArtOfIllusion/) vs.

Error creating GLCanvasDrawer: java.lang.UnsatisfiedLinkError: Can't load library: /mnt/develop/Shared/Source/ArtOfIllusion/out/Suite/localDeploy.dest/natives/linux-amd64/libgluegen_rt.so

when I launch from the deployment directory (localDeploy.dest/)

[Sailsman63]

I also tried hand-adding the *natives* jars to the application manifest classpath. No change. (Not that I was expecting any)

[Sailsman63]

All right, I think I found what's going on here.

The code is looking to load from

jar:file:/mnt/develop/Shared/Source/ArtOfIllusion/out/Suite/localDeploy.dest/lib/gluegen-rt-v2.4.0-rc4-natives-linux-amd64.jar

While the artifact that you provide is gluegen-rt-natives-linux-amd64-v2.4.0-rc4.jar

Note the order: gluegen-rt-<version-string>-natives-<os>-<arch>.jar vs. gluegen-rt-natives-<os>-<arch>-<version-string>.jar

Manually renaming the artifacts did allow me to launch and load the library.

Not sure if this is best fixed in the search code, or by re-uploading the artifacts.

EDIT: Adendum: I don't think that the loading code is expecting <version-string>s at all. It seems to be starting with the java .jar's base name. (gluegen-rt or gluegen-rt-v2.4.0-rc as the case may be) and appending the -<os>-<arch> pair.

[jzy3d]

Congrats, and sorry for missing your previous messages.

so I probably got wrong naming the version.

Re-uploading the jars with a correct name is easier. Modifying the loading code implies rebuilding all for all platforms which is tedious (and still require to te-upload the result).

[Sailsman63]

Modifying the loading code implies rebuilding all for all platforms

Plus would create a split between these builds and the upstream project.

I think that this got missed so far because other users are re-packaging all the contents as a "fat-jar" and therefore never hit the find-a-jar stage.

[jzy3d]

Plus would create a split between these builds and the upstream project.

The thing is that I am not sure the upstream project is still alive...

I can't promise to rebuild really soon. For now I analyse bugs, centralize them and indicate possible workaround when there are, and wait for companies willing to finance this work (it requires several days of work :/). I'll keep you informed there as soon as I am able to work on it.

[Sailsman63]

Okay. I do have a workaround for now. (re-naming the files as they are downloaded into an un-managed classpath space.)

I am not sure the upstream project is still alive...

I hear you. I'm starting to wonder if it would pay to switch to the other java OpenGL bindings...

[jzy3d]

Relates to https://github.com/jzy3d/jogl/issues/29 which provides a simple workaround.