[0.16.17] game does not start on Linux (library/.so issue)

[_Peter_]

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.

Code: Select all

Generating new string page texture 113: 256x256, total string texture memory is 5.60 MB
Generating new string page texture 114: 128x256, total string texture memory is 5.73 MB
GameAction [AppID 427520, ActionID 1] : LaunchApp changed task to SynchronizingCloud with ""
GameAction [AppID 427520, ActionID 1] : LaunchApp changed task to ProcessingShaderCache with ""
GameAction [AppID 427520, ActionID 1] : LaunchApp changed task to SiteLicenseSeatCheckout with ""
GameAction [AppID 427520, ActionID 1] : LaunchApp changed task to CreatingProcess with ""
GameAction [AppID 427520, ActionID 1] : LaunchApp waiting for user response to CreatingProcess ""
GameAction [AppID 427520, ActionID 1] : LaunchApp continues with user response "CreatingProcess"
Opted-in Controller Mask: 0
Game update: AppID 427520 "", ProcID 4335, IP 0.0.0.0:0
ERROR: ld.so: object '/home/ps/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/home/ps/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
/home/ps/.local/share/Steam/steamapps/common/Factorio/bin/x64/factorio: error while loading shared libraries: libsteam_api.so: cannot open shared object file: No such file or directory
>>> Adding process 4335 for game ID 427520
GameAction [AppID 427520, ActionID 1] : LaunchApp changed task to WaitingGameWindow with ""
>>> Adding process 4336 for game ID 427520
GameAction [AppID 427520, ActionID 1] : LaunchApp changed task to Completed with ""
Game removed: AppID 427520 "", ProcID 4335 

Downgrading to 0.16.16 solves the problem.

[sgr0]

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

[Meppi]

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

[rodsur]

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

[jmurrayufo]

Same thing here on Debian.

Code: Select all

factorio@factorioServer:~/Apps/Factorio/factorio_16_17/bin/x64$ uname -a
Linux factorioServer 4.9.0-4-amd64 #1 SMP Debian 4.9.65-3+deb9u1 (2017-12-23) x86_64 GNU/Linux

[Spice_King]

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.

[XGhozt]

Can also confirm, broken linux server.

[Loewchen]

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

[Zavian]

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 .

[Spice_King]

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.

[HanziQ]

Should be fixed in 0.16.18

[_Peter_]

Thank you, it is fixed for me in 0.16.18!