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.

There'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 Sep 2017 at 9:03 pm UTC

Do 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?

Looks 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).

But 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.

But 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

This "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?

By far one of the biggest issues with libs on Linux is glibc versioning. While they are not supposed to break the ABI, they frequently do. Making sure your game is compiled to use a sufficiently older version is a nightmare as well - you basically have to build your own GCC toolchain. I have found no other way of doing it.

IMO an rpath in the executable is a far better solution than manually dicking about with LD_LIBRARY_PATH. This way you would only have to have an rpath like "./libs.x86_64/" in your 64 bit executable, and "./libs.i386/" in your 32-bit one. A launch script using "arch" to identify whether the 32 or 64 bit executable should be launched takes care of the rest.

It is true that the Steam Runtime could use updating, however this would introduce problems as well for the same reason as using the system libraries introduces problems.

If it's glibc (and not libc++) can you not do like: https://web.archive.org/web/20160107032111/http://www.trevorpounds.com/blog/?p=103 ? Should be no reason to build a GCC toolchain, just download the appropriate libc package for your distribution that contains the older version and use the info from the link.

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.

You are wrong and here is why. All GNU/Linux distribution are the same OS. I Totally agree though that any game developer should not have to support different distros. So saying only ubuntu is "officially supported" is absolutely fine and good. On the other hand bugs found on other distros should not be completely ignored. They may prioritize as they like but completely ignoring because of the wrong mentality that different distros are different OS is very wrong. Especially Arch is the canary in a coal mine! If libraries broke because they upgraded they will also break on a future ubuntu release. It is that simple. I accept that developers do not care about the canary life ignoring it is also very bad omen.


Last edited by lucinos on 12 Sep 2017 at 5:37 pm UTC

If it's glibc (and not libc++) can you not do like: https://web.archive.org/web/20160107032111/http://www.trevorpounds.com/blog/?p=103 ? Should be no reason to build a GCC toolchain, just download the appropriate libc package for your distribution that contains the older version and use the info from the link.

That method is completely impractical - you would end up having hundreds of symver statements, and then it is no guarantee things would work properly. Similarly you would have to cook up the symvers for any library you wanted to build.

So then we are back to how we have always done things like this, keep a chroot around with those old versions of libs and compilers and build your stuff there. Now a days people perhaps use various containers for this instead, but I'm not there yet :)

Do 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.

I have no opinion. Just wanted to say I run steam-runtime on Manjaro.i3 + Intel i5 + Nvidia GTX without issues. If I ever had to (not once so far) I can run steam-native as well but so far I found out two games that don't run on native and run with valve's runtime, not the other way around.

You are wrong and here is why. All GNU/Linux distribution are the same OS. I Totally agree though that any game developer should not have to support different distros. So saying only ubuntu is "officially supported" is absolutely fine and good. On the other hand bugs found on other distros should not be completely ignored. They may prioritize as they like but completely ignoring because of the wrong mentality that different distros are different OS is very wrong. Especially Arch is the canary in a coal mine! If libraries broke because they upgraded they will also break on a future ubuntu release. It is that simple. I accept that developers do not care about the canary life ignoring it is also very bad omen.

The fact that the problem already got fixed by re-updating the library makes my point. It was a problem on the side of the libraries/OS and not on the side of the gamedev to necessary fix. And certainly not the gamedev to FIND all such bugs. That would be madness.

So yes. I strongly feel that asking for earlier bug squashing than 3-4 days (like here) on an unsupported distros is being way too entitled. Even more when the said distros is a rolling one, making it bleeding edge and obviously full of bugs/errors.

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.

See $LIB under the Rpath token expansion section of man ld.so.

Could shipping games themselves in Flatpak/Snap format mitigate this library breakage problem? From a practical standpoint, this would be a major turn-off to would be former Windows users who are used to their games running for 10+ years.

Could shipping games themselves in Flatpak/Snap format mitigate this library breakage problem? From a practical standpoint, this would be a major turn-off to would be former Windows users who are used to their games running for 10+ years.

flatpak is a step to the right direction but is not a complete solution yet. (snap - first I do not trust at all canonical as they are very responsible for the mess in the first place)

Windows is also a mess but they have been the major platform for many years so it is better. I do not doubt linux will be there in 10 years but I am quite angry and disappointing because we had a chance to do things right from the very beginning (that was 2012) but Valve and Canonical blundered miserably. If things were done right from the start this could actually be a great advantage of Linux against windows.

Flatpak isn't really a good solution. It's just basically shoving a huge tree of libraries into a folder and then making sure the app uses everything in that.

Sounds more like AppImage... I thought multiple flatpaks could all run on the same runtime, mitigating the amount of libs you'd have to bundle with each flatpak?

Jokes aside, going down that route has exactly the same problems in the end. I don't think flatpaks are the answer here either.

I think Flatpak is part of the solution. But we have to do something about glibc ABI breakage to really solve the problem.