Compiled template doesn't find steam_api.so

[ProbDenis]

So I compiled the export template for Godot 3.0 on Linux (both 32 bit and 64 bit) and tried to run a game with them. It gives me the following error, although libsteam_api.so is in the same directory as the excutable:

error while loading shared libraries: libsteam_api.so: cannot open shared object file: No such file or directory

I also tried the pre-compiled binaries and they give me the same error. The windows templates (which I cross-compiled on Linux) work just fine, detect the DLL and run the game. But the Linux binaries fail to find libsteam_api.so even though it's clearly there. Any idea what could be causing this behaviour?

[Gramps]

Hey there. Usually when I compile on Linux I have to add the: LINKFLAGS='-no-pie' Or it will give me this error when I try to run it. It is very possible I did not do this when exporting for the release file; I'll have to double-check.

Also, if you run (I believe) LD on the executable it may say it is looking for libsteam_api.so in your /usr/bin folder. There is a weird bit where Steam is supposed to copy the libsteam_api.so into that folder when it installs and it not doing so in some cases. To fix this you can symlink or move a copy of libsteam_api.so to that folder. DO DOUBLE-CHECK the folder location before doing so; provided that is where it thinks it is supposed to be. I'm not 100% why the compiled module would need this, but it does make a difference if this is the case.

Those two would be my guess. When I move back into my Linux environment I'll take a look at the pre-compiled releases and do an LD on it all. I believe one of those two things is your culprit.

[ProbDenis]

Thanks, I'll see if I can find anything. One thing that may be important is that I can still run an older game (for Godot 2.1) that uses GodotSteam. For that game I compiled the Linux binaries in the same way earlier this year. These binaries still work and actually find the library, the new ones don't.

[Gramps]

Hmm, might be the way Godot 3 is built. For the most part, the modules for Godot 2 and Godot 3 are identical; save functions that no longer exist or things that were renamed.

Let me know what you dig up and I'll report back when I start digging around too. I have a game update to export with 2.1.4 and a different one to export with 3.0.2 so I'll see what happens.

The biggest pain has be GDNative, which I have shelved until they get a finalized core version of it down. It changes too much each iteration to keep up with.

[Gramps]

Well, I tested my game export with the pre-compiled 3.0.2 template in releases section and it worked. I did have the libsteam_api.so in the same folder as the exported executable.

Running LDD on my executable shows this: libsteam_api.so => /usr/lib/x86_64-linux-gnu/libsteam_api.so

The file was, I assume, installed there by Steam. This might mean the libsteam_api.so doesn't need to ship with the executable, but I always do it for good measure.

[ProbDenis]

Okay, so Steam doesn't install the library for me. I just made a fresh install and it's nowhere to be found in /usr/lib That means I can't rely on it being there when I ship my game, because other users may run into the same problem. I wonder why the 2.1.4 executable finds the library in its own folder and other Steam games work just fine, while the 3.0.2 binary doesn't find the library. Maybe it has something to do with the build configuration?

Anyway, there's probably a workaround for me now. I think I can write a script that adds a local lib directory to LD_LIBRARY_PATH and then execute the game. I tried it and it works from the command line, so I hope it'll also work when executing from Steam.

[Gramps]

Hmm. What did running LDD on your executable say?

I had this error when playing other games on Linux in Steam. I believe a few actually run a .sh file which uses LD_LIBRARY_PATH then executes the game itself, like you are proposing.

Yeah, I'm not sure what in the build configuration would cause this in Godot 3. Not sure if it is something with the module building process or if it's in the Godot 3 source itself. I'll dig more and see if I can find anything out. If you come across something, let me know!

[ProbDenis]

LDD just told me that it couldn't find the library, but didn't tell me where it was looking. But when I made a link to it in /usr/lib/... it worked, so it's clear that it looked for it in the usual places, but not in the current working directory. I got it working by setting LD_LIBRARY_PATH, so for now I'm happy that the game is starting and the Steam features are working, so the game can be released with this workaround.

[Gramps]

Interesting. Yeah, something must be wonky somewhere. Glad your work-around is working though!