"Cannot open shared object file" but it's there! about godotsteam HOT 35 CLOSED

Actually, thank you for linking me to that other issue - that solved the problem, nothing to do with re-compiling (as I expected - since the precompiles had the same issue), I copied libsteam_api.so into usr/lib, et voila, the newly compiled Godot2Steam runs (godot.x11.opt.64.llvm).

My issue now is, much like the guy in the other thread was having to address, is what do I do for the Linux build of my game? I don't know how to give the right privelage to a script that it will be allowed to copy a file to usr/lib on the customer's system, which in my limited Linux knowledge, I know that you can't just fiddle with that stuff without typing "sudo" and using your password...

That's a different issue of course, you don't have to address that here... but this original issue is solved by copying the library libsteam_api.so, into usr/lib !

from godotsteam.

Ah I will get the fix then. No worries, very glad I could help and the framework is improved :)

from godotsteam.

Ah, thank you. OK so modules are the way to go after all :)

This is crazy - hours after I posted this to you, I got a notification from an old FMOD forum thread that I posted to last year - turns out 2 months ago, someone did exactly this - make an FMOD module for Godot!
https://qa.fmod.com/t/integration-in-godot-game-engine/14131/2

from godotsteam.

I ran into this issue searching the web for people with a similar issue I have with my jobs Godot module and found a solution to this. Adding the .so file to the root of the godot project seems to solve the problem. I thought I wanted to add it here to avoid adding the .so file to /usr/lib.

from godotsteam.

That does indeed sometimes work. Sometimes it does not, depending on how Steam is installed on the user's system. Valve may have fixed this since then, hopefully. Running a launch script with LDD in it is usually the safest bet.

from godotsteam.

Hmm, I want to say this has occurred in Linux before but I can't quite remember off the top of my head. I've never compiled it with Clang though I highly doubt that's what's going on.

Do the pre-compiles act the same way?

I wanted to touch base and will report back after some research.

from godotsteam.

I just tried the precompiled "Godot 2.1.5 - Steamworks 1.42 - GodotSteam 1.9.1" and yes, it behaved the same way... For what it's worth, I checked the permissions on the libsteam_api.so file and the godot files, and everything is set to read/write and executable for the current user.

I should give you some extra info;

I'm on Ubuntu 18.04.1 LTS

When I got to "scons platform=x11" I got the following message;

scons: Reading SConscript files ...
Your configured compiler appears to be GCC 7, which triggers issues in release builds for this version of Godot (fixed in Godot 3.0+).
You can use the Clang compiler instead with the `use_llvm=yes` option, or configure another compiler such as GCC 5 using the CC, CXX and LD flags.
Aborting..

So I installed clang with "sudo apt install clang" and then used the other option; "scons platform=x11 use_llvm=yes". Both Godot and the tools compiled successfully. But both of them give this same error.

from godotsteam.

Ah, OK. Not sure if the official Godot documentation mentions it, sadly I did not, but Godot 2 must be compiled with GCC/G++ 5.

Install that then use:
sudo update-alternatives --config GCC

And, naturally:
sudo update-alternatives --config g++
Then swap it to 5, which can be swapped back by the same mehtod. That'll fix your compiling issues.

from godotsteam.

I’m going to try it in the morning, but my big question for now is - why would the (assumedly) correctly compiled “pre-compiles” exhibit the same behaviour?

from godotsteam.

It is most likely looking for the official libsteam_api.so that Steam should install on Linux, related to a previous and similar issue: https://github.com/Gramps/GodotSteam/issues/32

It seems to occur for some Linux users and not others; I can't really say why for sure.

from godotsteam.

Glad that got it sorted for you. As far as I remember the issue is more of how Steam installs itself and a failure to put the libsteam_api.so in the right place. I believe it is and has been a somewhat common issue with just the Steam installation. I have had it happen a few times on fresh installs and had to move the file.

That being said you really don't have to do anything to "fix" it as it's a problem with a user's Steam installation.

However, I believe you could create a .sh script that Steam runs which will point it to the .so file and executable:

LD_PATH=.  <your game executable>

That should tell it to look for the shared library in the current directory when launching. Then just set it to run this .sh script in the Steamworks settings on Valve's site.

Lastly it might be fixable by changing the compiling process goes so that the executable is looking for it dynamically. If you run, I think, 'LD' on the executable it will show where it's looking for the libsteam_api.so at. So somehow that would need changed. Which I haven't quite figured out.

All in all I should make a note of this in the documentation so people are aware. As well as figure our the linking thing too.

from godotsteam.

Also if you so a search for:

steam, Linux, libsteam_api.so missing

You'll find a ton of posts about this exact issue with a bunch of suggestions on fixes as, again, it's fairly common on every game engine.

from godotsteam.

Oh wow, ok. I didn't suspect Steam, so my searches were more broad "Linux missing .so file" searches. I think from your initial response I took it to be a "Linux thing" (just a misunderstanding). This makes more sense now - I suppose the Steam code is perhaps running from a different location than the program?

from godotsteam.

Yep, I believe it is more how Steam installs. Like I said, most fresh installs I don't have that issue and a few I do.

Honestly when I ship Linux version of my games I don't do anything special. But if you choose to there are a few options.

There might be a way to make the executable look for it in the same folder instead of the/use/lib folder but Steam should have put one there by default.

from godotsteam.

So... if you don't do anything special, what's really going on here? I looked at the search results you sent and I saw developers posting a message to their users that they're sorry for breaking things after implementing steam achievements and looking to fix it. It sounds like something I need to do for every steam game...

from godotsteam.

So one thing you can do that might make a difference, in the config.py file this line is commented out:
env.Append(RPATH=["."])
Uncomment it and then compile. This will make the libsteam_api.so linked to the directory the executable is in and prevent the user from having to add libsteam_api.so to the /usr/lib folder if Steam's installation process did not do it. I have pushed a correction to the repos which adds that line back in.

Also to answer your question, prior to the fix I just pushed, if you don't do anything special then your game is looking for libsteam_api.so in the /usr/lib folder where the Steam installation should have placed it. Sometimes the installation does not do this; sometimes it does.

You game's executable can be run through a wrapper with the LD_LIBRARY_PATH export but that's just a crutch for not having the executable look for the libsteam_api.so file in the local directory.

Either way, thanks for bringing this issue back up so that I could find that commented line and fix it! It'll save others a headache down the road!

from godotsteam.

Excellent. And thanks again! The bugs are good opportunities to improve stuff and better learn how it all works for us all!

from godotsteam.

Hey Gramps - so did you update the pre-compiled for Godot 2.1.5 to include this fix?
I downloaded this one and removed the libsteam_api.so from my usr/lib to check if it fixed it, and it didn't. libsteam_api.so exists in the same folder as the linux-engine-215-64bit executable.

https://github.com/Gramps/GodotSteam/releases/tag/g215-s142-gs192

from godotsteam.

Well, shit. Apparently I'm an asshole because I didn't use the correct fix when compiling it! I'll re-compile and re-upload it when it's ready. Sorry about that!

from godotsteam.

Annnnnnd the release is updated! Sorry about the inconvenience!

from godotsteam.

Man I'm still getting the same error. Downloaded from that link again (I can see you updated it not long ago), put the files in the folder, if I run "linux-engine-215-64bit" by itself it starts ok, but as soon as I run my project, it gives the same "libsteam_api.so:cannot open shared object file" error as before. (that's a shortened version of the error)

Literally the only way I've been able to get this to run is by manually placing libsteam_api.so in the /usr/lib folder.

from godotsteam.

Hmm. When you run ldd linux-engine-215-64bit where does it say libsteam_api.so is linked to? Pretty sure I checked it before zipping and uploading.

from godotsteam.

Here's the output for that command (I realise this may be overkill for what you asked for but I want everything as transparent as possible, I even have the command included);

domarius@Domarius-Ubuntu ~/Apps/Godot2Steam $ ldd linux-engine-215-64bit 
	linux-vdso.so.1 (0x00007fff75f90000)
	libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f8566359000)
	libXinerama.so.1 => /usr/lib/x86_64-linux-gnu/libXinerama.so.1 (0x00007f8566156000)
	libXcursor.so.1 => /usr/lib/x86_64-linux-gnu/libXcursor.so.1 (0x00007f8565f4c000)
	libXrandr.so.2 => /usr/lib/x86_64-linux-gnu/libXrandr.so.2 (0x00007f8565d41000)
	libXi.so.6 => /usr/lib/x86_64-linux-gnu/libXi.so.6 (0x00007f8565b31000)
	libssl.so.1.1 => /usr/lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007f85658c7000)
	libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007f856544f000)
	libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f856519b000)
	libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16 (0x00007f8564f69000)
	libasound.so.2 => /usr/lib/x86_64-linux-gnu/libasound.so.2 (0x00007f8564c62000)
	libpulse-simple.so.0 => /usr/lib/x86_64-linux-gnu/libpulse-simple.so.0 (0x00007f8564a5d000)
	libpulse.so.0 => /usr/lib/x86_64-linux-gnu/libpulse.so.0 (0x00007f856480d000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f85645f0000)
	libGL.so.1 => /usr/lib/x86_64-linux-gnu/libGL.so.1 (0x00007f8564364000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f8564145000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f8563f41000)
	libsteam_api.so => ./libsteam_api.so (0x00007f8563ce5000)
	libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f856395c000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f85635be000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f85633a6000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8562fb5000)
	libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f8562d8d000)
	libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f8562b7b000)
	libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007f8562971000)
	libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007f856276b000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f8562563000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f8566691000)
	libpulsecommon-11.1.so => /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-11.1.so (0x00007f85622e5000)
	libdbus-1.so.3 => /lib/x86_64-linux-gnu/libdbus-1.so.3 (0x00007f8562098000)
	libGLX.so.0 => /usr/lib/x86_64-linux-gnu/libGLX.so.0 (0x00007f8561e67000)
	libGLdispatch.so.0 => /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0 (0x00007f8561bb1000)
	libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f85619ad000)
	libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f85617a7000)
	libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007f8561523000)
	libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x00007f8561319000)
	libsndfile.so.1 => /usr/lib/x86_64-linux-gnu/libsndfile.so.1 (0x00007f85610a0000)
	libasyncns.so.0 => /usr/lib/x86_64-linux-gnu/libasyncns.so.0 (0x00007f8560e9a000)
	libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007f8560c85000)
	liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f8560a5f000)
	liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x00007f8560843000)
	libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007f8560528000)
	libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007f856030e000)
	libFLAC.so.8 => /usr/lib/x86_64-linux-gnu/libFLAC.so.8 (0x00007f8560097000)
	libogg.so.0 => /usr/lib/x86_64-linux-gnu/libogg.so.0 (0x00007f855fe8e000)
	libvorbis.so.0 => /usr/lib/x86_64-linux-gnu/libvorbis.so.0 (0x00007f855fc63000)
	libvorbisenc.so.2 => /usr/lib/x86_64-linux-gnu/libvorbisenc.so.2 (0x00007f855f9ba000)
	libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f855f79f000)
	libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007f855f58a000)
domarius@Domarius-Ubuntu ~/Apps/Godot2Steam $ 

Oh and here's the directory listing for that folder;

domarius@Domarius-Ubuntu ~/Apps/Godot2Steam $ ls
godot.x11.opt.64.llvm    libsteam_api.so         linux-template-215-64bit
godot.x11.tools.64.llvm  linux-engine-215-64bit
domarius@Domarius-Ubuntu ~/Apps/Godot2Steam $ 

from godotsteam.

Hmm, everything looks fine. LDD shows it's looking for the libsteam_api.so in the current local directory. But it still errors when you run the game?

from godotsteam.

Yep. "Linux is so much better than Windows" they said. "Everything 'just works' in Linux" they said. No effing way, Linux, on the whole, has been waaaay worse than Windows. Managable at best. (I've used Linux Mint, and Ubuntu, so far). The best thing about it is it's free, and it's impressive when you see it from that perspective. But no way is it better. Yes for servers, I can understand that. But not desktop users. Anyway, rant over...

Well, as you can see, the .so file is in the local folder, with the correct name. And it still gives that same error when running the game. Clearly this is some obscure issue... I bet the reason the line was commented out is because it didn't really fix it in the first place, it seems too obvious.

So from what you're saying, when someone installs Steam, the libsteam_api.so should automatically be placed in the /usr/lib folder, and if it doesn't, it's an error.

Maybe I should just release the game without doing anything special and cross my fingers that people don't run into this problem? I have been getting other strange problems on Ubuntu, maybe a re-install would fix it, I don't know...

This is a fairly recent thread about it, I wish I knew what the developer did to fix it for everyone;
https://steamcommunity.com/app/718670/discussions/0/1692669912383268531/
I see this thread where the solution is to manually copy the libsteam_api.so into your /usr/lib folder yourself!
http://unrealsoftware.de/forum_posts.php?post=420855&l

from godotsteam.

Yeah, they each have their gives and takes. I've been dual-booting for a long time with headaches on both sides of the fence.

Not sure why the line was commented out. When it was, it looked for libsteam_api.so in the /use/lib folder and when it wasn't it looked locally.

Yeah, if memory serves me, Steam sometimes doesn't install it correctly. I saw that mentioned somewhere when I had an issue with Steam on Linux; I have to simlink that file to the right place.

I wouldn't worry about doing anything special. I never do and haven't had any issues come up. Anyone who might have an issue has probably come across this already and "fixed" it on their system.

You could try contacting the developer and asking. There are a few fixes I think I mentioned prior. And, of course, you could leave it until someone hits a snag.

Sorry I couldn't be of more help.

Side note, how did you install Steam on Linux and what video card do you use?

from godotsteam.

Windows 7 has its quirks yes, but overall I'm having way more trouble in Linux Mint / Ubuntu. Also Windows 7 is just snappier and more responsive, just filebrowsing even, and type-ahead works perfectly (and if you don't know what that means, I didn't either, it's something that I just got used to being a part of filebrowsing, until Ubuntu did it badly and I had to look up what was wrong!) Anyway...

Sounds like it's better off that the line was uncommented anyway.

Well, I will resign myself to assuming that libsteam_api.so should be in usr/lib and if it isn't, it's not my fault...

Well initially I installed Steam from the Ubuntu Software Center. Video card is a Geforce GTX 1050 (just curious, why did you need to know?) But as an experiment just now, I tried uninstalling and re-installing steam. Big mistake. I hit so many snags, one of which was after installing Steam from the .deb file off Steampowered.com, get an error popup "Steam can't setup data" or something. I looked up where to delete some extra files, restarting seemed to help, and I'm finally back where I was - using the one from the Software Center, which works. Must be a Ubuntu optimised copy... this is the Linux shit I'm talking about! It's not surprising if it's worse than Windows, because it is free after all, I just wish people wouldn't evangalise it so much...

Anyway... you've been awesome, I really appreciate your help so far, thanks :)

from godotsteam.

Haha, honestly not 100% sure what type-ahead is. Though I feel like I've heard it before.

Yeah, before when it was commented that weird libsteam_api.so issue was even more prolific.

Hmm, OK. I think the Ubuntu Software Center version is different from the .deb from Steam's website. I want to say that's the version I used when it didn't install libsteam_api.so to the /usr/lib folder; which might be why yours didn't either. Not 100% sure though. Next time I do a clean wipe or set up a VM, I'll test that hypothesis.

I asked about the video card because I remember there being some weird issue with Steam on Linux with certain card's drivers. Though honestly I don't know that is related to this particular issue.

Haha, fair enough. They each have their merits. I like Linux better for programming and compiling. There's generally less mess than with Windows and Visual Studio. I worked with a lot of Linux servers and environments in the last 14 years so I tend to lean towards that. In all honesty, the best is a dual-boot system so you can leverage each.

And thanks, sir! Glad I could be of help... or at least what help I could provide!

from godotsteam.

Well, if you're interested; type-ahead is that thing where you just start typing with the file browser open on a list of files / folders, and it jumps to the one in the list that first matches what you're typing, but as you type. So if you want to find "Sonic the Hedgehog.png", a rather long filename, you start typing; S... O... N... and by the time you're on N it's probably selected the file you want, unless you have a lot of files that also start with those 3 letters. In Windows 7, navigating folders is like; type 2/3 letters, enter, type 2/3 letters, enter, type 2/3 letters, enter - when you know your folder structure, it's a super quick way to navigate around. In Ubuntu it's like - type 2/3 letters, enter... wait for the file list to load or it'll ignore you and start and the 3rd letter... etc. etc. In Windows if it can't catch up, it buffers the keystrokes, so you'll get there. Ubuntu just ignores you and randomly starts listening when its ready, breaking the flow! Also, in Ubuntu 18.04 they patched it out so that it searches (instead of having the search as an option, like before), and you have to download a patch that someone made, to patch it back in... You know, Windows has had this since Windows 3.1 (I went back and checked!) it seems ignorant of Ubuntu to remove such a standard OS feature.

Looking forward to see if your hypothesis works - I tried to test this myself, but the .deb file from Steampowered just plain didn't work, so I'll never know, for the time being.

Yes I know what you mean - I don't think I've fully leveraged how useful Linux can be for compiling, but I do like how when you need a library, eg. SDL, you just "install SDL" and now you have SDL. You just need a compiler flag. It's actually kinda ironic that it's Windows that needs more file management from the user when it comes to referencing libraries or even just installing software. It took until Windows 10 for it to have a "Software center" like Ubuntu or the others have.

from godotsteam.

Ahhh, OK. I have no idea what I thought that was called instead.

Yeah, once I get some stuff out of the way, provided I hit my deadlines, I might just do a VM version since I don't need any fresh installs. I kinda think that's what happens but if I'm right I'm not sure how to submit that to Valve.

Indeed. Easier to get what you need quickly. I think Linux is tilted more towards 'power users' and less towards the average or below average user. Oddly enough, my mom was moved to Ubuntu about six years ago and she loves it... with the occasional (minor) problem she can't figure out.

from godotsteam.

Yes I think for non-computer savvy people Ubuntu might be better since they can install software more easily with the software center - possibly even if they are installing on a brand new machine they can do that themselves as well, with only a few instructions from a computer savvy person. This is all very ironic given the target market for Linux vs Windows...

from godotsteam.

Yeah, it seemed to work for her pretty well. Granted I did give her some basic commands to run like sudo apt autoremove to get rid of used kernels and such.

from godotsteam.

I saw the CoaguCo website is listed as your contact, with the support email, but I figured it'd be more direct to just comment here, hope that's OK. I'm interested in hooking up FMOD to Godot just to be able to play those old tracker music file formats (MOD, S3M, IT etc) and it seems like GDNative is the recommended way to do that. The GDNative page even suggests that one could implement the SteamWorks library using GDNative, but you've made it as a module. So since you seem to know what you're doing I thought I'd get your opinion on why you implemented it as a module instead, and if GDNative & FMOD is still the best way for me to play tracker songs?

from godotsteam.

Sure, either or is fine with me!

Some folks are big on the newer GDNative way of adding stuff, but I personally am not a fan. I've tried getting GodotSteam to work on GDNative and always run into a ton of issues. Since it also needs compiled like the modules does, but also requires a bunch of additional hoops to jump through, I do not see it as a better solution for anything. It has more steps and more places for things to go wrong.

That being said, I would probably try to integrate FMOD as a module instead of GDNative; though you'd probably find plenty of folks willing to argue the opposite.

from godotsteam.

I definitely think it is. Less headache.

Haha, what the! That's awesome! Saves you having to port it provided it works the way you wish. That's great news!

from godotsteam.