Open Sailsman63 opened 2 years ago
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?
Thanks for the update. I've confirmed that this is not the same as #21.
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.
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 :)
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 UnsatisfiedLinkError
s, 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/
)
I also tried hand-adding the *natives*
jars to the application manifest classpath. No change. (Not that I was expecting any)
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.
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).
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.
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.
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...
Relates to https://github.com/jzy3d/jogl/issues/29 which provides a simple workaround.
(Possibly related to #21 )Arch Linux on amd64 Both openJDK and Temurin builds for JDK11 and JDK17 Both
rc-20210111
andrc4
builds of joglWhen 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 togluegen-rt-natives-linux-amd64
(without the version coding)gluegen-rt.jar
andjogl-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.