[elf/linux] demo does not start [fix provided]

[MrΩ]

in the log:
Exception in thread "main" java.lang.UnsatisfiedLinkError: Failed to dynamically load library: /tmp/lwjgluser/3.3.1-SNAPSHOT/libopenal.so

Fix below.

[foxel_]

Well that's not great. I haven't been able to reproduce this on Ubuntu or Steam Deck yet, I'll see what I can do. In the meantime, running via Proton might sidestep this.

[MrΩ]

Ubuntu linux or arch linux(deck), I am pretty sure both do not have /tmp/lwjgluser/3.3.1-SNAPSHOT/libopenal.so

mmmmh... it may be an audio fallback bug: try to run you game with the pulseaudio(or pipewire) mixer server disable (on ubuntu linux, because I don't think you have that much control on the deck default linux). My elf/linux distro is lean, namely running audio with alsa[dmix] (the only audio interface you need to support on linux based OSes).

#noproton

(EDIT) ---

I just inspected my /tmp directory and I saw that you did copy your binary of libopenal.so there!!
So there is a real dynamic loading issue, and I lack detailed information about it from the log.txt in order to figure out what's wrong, since I have all the libs required by libopenal.so (using the binutils readelf utility).


####### IMPORTANT READ BELOW:

(EDIT) --- I "probably" found the issue: I made loader for your libopenal.so, and it seems to be a c++ ABI issue (again...). I tried the steam runtime and "heavy" steam runtime libstdc++, and it refuses to load with the following error message:

/home/user/.local/share/Steam/ubuntu12_32/steam-runtime/usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.22' not found (required by /tmp/lwjgluser/3.3.1-SNAPSHOT/libopenal.so)

I tried a very recent libstdc++ (gcc 12), and I get the following error message (probably one of the endless c++ ABI issues):

/tmp/lwjgluser/3.3.1-SNAPSHOT/libopenal.so: undefined symbol: _ZTINSt6thread6_StateE, version GLIBCXX_3.4.22

To fix all of this, you need to compile/link your binaries with the "-static-libstdc++ -static-libgcc" options, and link them with the oldest set of glibc libs as possible (to work around most if not all GNU versioning issues).

[foxel_]

These native libraries are packaged and provided by LWJGL directly, I don't have a process or environment set up to compile them myself. I'll try and find time in the future to harden Linux support, but contacting the LWJGL project might be a better solution.

[MrΩ]

allright, dunno those guys. You can give them this post URL, their elf/linux guys will understand.
Well, you do you.

[foxel_]

Some good news; this is allegedly already fixed in LWJGL 3.3.2. I updated the demo to that version, but I can't test it on any of my machines. Give it a shot if you want

[MrΩ]

I'll test it. For the moment, I only get the 3.3.1 based demo. Should be deployed everywhere soonish I guess.

EDIT: Got an update of the demo, but still at 3.3.1.

[foxel_]

Blargh I missed a gotcha in the build process. Sorry for the runaround, I uploaded a for-real-this-time updated build.

[MrΩ]

Got the right one, loading properly... but I don't have a joypad right now and:

java.lang.NullPointerException: Cannot invoke "java.nio.ByteBuffer.limit()" because the return value of "org.lwjgl.glfw.GLFW.glfwGetJoystickButtons(int)" is null
21 at main.Input$Gamepad.<init>(Input.java:118)
22 at main.Input.onPadConnect(Input.java:493)
23 at main.Input.createPadCallback(Input.java:488)
24 at main.Input.<init>(Input.java:394)
25 at main.Input.getInstance(Input.java:48)
26 at main.RootLayer.update(RootLayer.java:153)
27 at mote4.scenegraph.Window.loop(Window.java:273)
28 at mote4.scenegraph.Window.loop(Window.java:241)
29 at main.Main.main(Main.java:87)

Joypad mandatory? Or did the lwjgl guys did test their "no joypad" fallback code path?

EDIT: I did connect a joypad F310, got my /dev/input/eventXX files, did give the devices files write access, and I get the same crash. I would bet they use the deprecated (for more than a decade) "js" interface instead of the expected /dev/input/eventXX interface? (I don't even compile the "js" interface, dunno if it will even compile).

Additionally, opengl is being deprecated and replaced by vulkan. I would expect a new engine with a vulkan backend (unreal removed its opengl backend, like dota2, etc).

(the joypad does work properly, is detected properly by steam etc...)

[foxel_]

I hardened some of the gamepad code in b0.4.4 which should prevent this crash, hopefully. I've only encountered this bug myself on very outdated Mac installs. Enabling Steam Input for your controller might help circumvent some of this, but barring a full rewrite to use the Steam Input API exclusively, this will be the state of gamepad support for a while.

[MrΩ]

I played the demo (I was a heavy wipeout HD player on PS3), so here it is:

1 - I could use the keyboard, but on the title screen if I press a key, it will crash.
2 - As I said I did compile the old linux joystick driver for linux, and as expect everything started to work. So your game engine uses the old linux joystick driver. It should use /dev/input/eventXX device nodes instead (steam input on linux is actually based on that).
3 - You are now aware that the c++ ABI is toxic and how to work around it, or at least identify it.
4 - A corollary of the previous point: the glibc is very not backward compatible, you need to build your binaries on the oldest set of glibc libs you can run, or your binaries will very probably refuse to load on any elf/linux using a set of glibc libs older of the ones you did use for you build (and usually due to no really pertinent reasons).
5 - opengl is _really_ being removed everywhere, your game engine devs should seriously work on a vulkan3D backend (vulkan code and shaders should be very conservative to maximize compatibility, since vulkan is very close to modern hardware, it is very ez to get hard crashes with fancy code or shaders).
6 - You did the right thing distributing your jvm elf/linux binaries, as all java based games should (ofc, some don't...).

That's all folks, I thank you for your time... and demo ofc!