Factorio Forums

On Ubuntu 16.04.3 (xenial) after upgrading to 0.16.7 the game does not start anymore.

Logfile is not updated, but if I start steam from the shell and try to load Factorio I see the following.
Downgrading to 0.16.16 solves the problem.

I am using Ubuntu 17.10 and also cannot start the game after update to [0.16.17] - likewise a downgrade to [0.16.16] fixes the problem

Same for me on Fedora 27 0.16.16 works fine

Meppi wrote:Same for me on Fedora 27

Code: Select all

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

0.16.16 works fine

same thing happening here in Ubuntu 16.04

Same thing here on Debian.

It's a goof on the devs part. Easy to fix, just add LD_LIBRARY_PATH="lib/" before calling bin/x64/factorio, like this: LD_LIBRARY_PATH="lib/" bin/x64/factorio

Should note that at this point, it's kinda moot as you get hit with an error for libpng after it starts up.

Can also confirm, broken linux server.

See: viewtopic.php?f=7&t=56934

This actually looks to be a different bug than viewtopic.php?f=7&t=56934 (though it is probably related). This bug is about missing libsteam_api.so . viewtopic.php?f=7&t=56934 is about libssl.so.1.0.0 .

Zavian wrote:This actually looks to be a different bug than viewtopic.php?f=7&t=56934 (though it is probably related). This bug is about missing libsteam_api.so . viewtopic.php?f=7&t=56934 is about libssl.so.1.0.0 .

Yes, it's a different bug. You are only half right on how they are related. They relate only in how there is a missing library binary. libssl.so is a library not included in the download of Factorio, but a system library. You can debate if it's an issue of an OS not including it (or faking that version), or Factorio asking for an outdated, known vulnerable version of a security library.

The libsteam_api.so error stems from one simple error, forgetting to inform the dynamic linker of where Factorio kept it's copy of the library. Some use a shell script to set the LD_LIBRARY_PATH variable to include the path they used, of which I have seen in some games on Steam. What 0.16.16, and I assume older version have also used, was setting the factorio binary's library runpath inside the ELF header.

0.16.16 has it set to $ORIGIN/../../lib which translates to being relative to the factorio binary and successfully finds the library. You can see this by running the tool called readelf like so: readelf -d path/to/Factorio/bin/x64/factorio

Now with the 0.16.17 binary, the same command says that the library runpath is /tmp/factorio-e1OoI4/libraries/steam/linux64 which I assume was on the build server. Of course, no one has this path on their Linux system by default, let alone with the correct copy of the libsteam_api.so in side. I assume this is an error, but I'm unsure how this came to be. Someone messed with compiler/linker settings? Some tool failed silently? I can't tell, and, personally, don't care how.

As a side note, other than using the LD_LIBRARY_PATH variable trick to fix this, there is a tool to just patch the binary and fix the over site directly, simply called patchelf. Creative name, I know. One quick command later, and the 0.16.17 binary is fixed for the libsteam_api.so issue. (patchelf --set-rpath '$ORIGIN/../../lib' bin/x64/factorio) That said, it's a pointless fix right now as the binary is still pooched due to Factorio being compiled with the headers from libpng version 1.2.50, but the version statically linked in is version 1.6.20. libpng then, rightly so, has a fit about the miss match, and Factorio has no choice but to die with an error. The post here talks about it: viewtopic.php?f=7&t=56922

All and all, this was fun to a degree to peel apart and dissect. Much like a factory having issues.

Should be fixed in 0.16.18

Thank you, it is fixed for me in 0.16.18!