A bunch of Feral Interactive Linux ports may be broken on Arch and others, here's a possible workaround

Tested Mad Max and Tomb Raider and can report no issues.

Running Manjaro Xfce.

Quoting: sbolokanov

Quoting: GnurfosThere's something I don't understand, can someone clarify :

• In addition, why would there be libs already present in a game's folder, which are not used by default by the game launcher ?

The problem is that it can't find thouse game libs. That's the whole problem.

I got that, but why bother putting these libs in the game's deliverable in the first place, if the game launcher does not set LD_LIBRARY_PATH pointing to their containing folder ?

I've looked a bit closer at this, and it seems that Feral / games with this issue use glibcs hwcaps to determine the architecture. Formerly, it reported x86_64 on all x86_64 platforms, and seems to have moved on to reporting either haswell or xeon_phi (side-note, for x86 it reported i386, i486, i586, i686, so managing different x86_64 platforms actually makes sense on a long-run).

Not sure if we can lay that out as ABI break, but it seems very much like it, since it used to report something different from 2.25 to 2.26.

Fact is, I'm a not so sure if it's wise to rely on hwcaps for determining the target platform, or in other words, rely on it to determine the path for your platform specific libraries.

It should be pretty easy to fix for Feral if they want to, but they'd have to do that for all their games...

But doing getconf LONG_BIT or uname -m seems more reliable than going for glibcs hwcaps which can be subject to change on new architectures.


Last edited by STiAT on 11 September 2017 at 9:03 pm UTC

Quoting: cprnDo you not run Steam runtime anyway? I see no point in running native libs that might or might not work with a particular title. It's way more effective to just use what's provided and tested.

try to run steam runtime on intel or amd. It does not work. You need steam-native. System libraries should not had been on steam runtime they only make the problem worse.

You switched back to Ubuntu? Did your original frustrations with it go away?

Quoting: Guest

Quoting: GuestLooks to only have the path compiled in. Not sure that's a wise idea. Not guarantee that the target system is using the same file tree.

You can set a relative rpath too, which should be fine for a subdir of the game’s directory.

But then you'd need a convention for what working directory the steam games should be run from (maybe this exists already).

Quoting: GnurfosBut then you'd need a convention for what working directory the steam games should be run from (maybe this exists already).

You can declare a rpath relative to the binary.

Quoting: GuestBut I must admit, I'm a little tired too... Arch Linux is widely used and some developers should notice this earlier or at least provide an option to directly send the crash report without the need to visit a forum.

Are you talking about game developers or library developers? It shouldn't be the game developers job to check every unsupported version of Linux for bugs. Even more when it would be a constant mess anyway. It's the community's job to find bug and trying to report it. And they frankly shouldn't except fixes if they use unsupported OS.

Why not using the steam flatpak and forget about all this problems? Its available in flathub already: https://flathub.org/apps.html . Direct link: https://flathub.org/repo/appstream/com.valvesoftware.Steam.flatpakref

Quoting: GuestThis "work-around" doesn't work for me(I'm on a fresh arch). Tomb Raider runs fine but Mad Max, Life Is Strange and Total War: WARHAMMER crashes. Edit: I've tried to pass it as `LD_LIBRARY_PATH="~/.steam/steam/steamapps/common/Total War WARHAMMER/lib/x86_64/" %command%` and `LD_LIBRARY_PATH="/home.../.steam/steam/steamapps/common/Total War WARHAMMER/lib/x86_64/" %command%`.

So if you do, cd "~/.steam/steam/steamapps/common/Total War WARHAMMER/lib/x86_64/" you get to correct folder?