You can sign up to get a daily email of our articles, see the Mailing List page.
We do often include affiliate links to earn us some pennies. See more here.

It seems an update of glibc has caused a bunch of Linux ports from Feral Interactive to be broken. Here's a possible workaround for now.

Add this as a launch option:

LD_LIBRARY_PATH="/path/to/steam/games/steamapps/common/gamename/lib/x86_64/" %command%Set it to the correct install path and replace "gamename" with the name of the game.

That can be placed by right clicking the game in Steam, going to Properties, hit Set Launch Options and put that in.

While stuff like this doesn't happen too often, it is one of the problems of being on a rolling distribution. Updates can break stuff! It's why even after I posted about how I loved Antergos, I'm back and happy on Ubuntu on my main gaming machine, so I don't have to deal with stuff like this.

I've emailed the PR people at Feral Interactive to let them know, and to see if we can get a comment on what they plan to do. It's worth noting the bug was reported to them nearly a month ago and so they should already be aware.

Hopefully this will be sorted before too long. Feral will need to sort it, since Ubuntu and others will update before too long. It could be a regression in the updated packages and not intentional to be fair, so it might not be Feral's problem to solve.

Article taken from GamingOnLinux.com.
8 Likes
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly. Find me on Mastodon.
See more from me
The comments on this article are closed.
53 comments
Page: «4/6»
  Go to:

F.Ultra Sep 12, 2017
View PC info
  • Supporter
Quoting: GuestBy 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.
lucinos Sep 12, 2017
Quoting: FitzOmegaAre 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 September 2017 at 5:37 pm UTC
F.Ultra Sep 12, 2017
View PC info
  • Supporter
Quoting: Guest
Quoting: F.UltraIf 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 :)
cprn Sep 13, 2017
Quoting: lucinos
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.

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.
FitzOmega Sep 13, 2017
Quoting: lucinosYou 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.
N30N Sep 14, 2017
Quoting: STiATI'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.
Dolus Sep 14, 2017
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.
lucinos Sep 14, 2017
Quoting: DolusCould 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.
Dolus Sep 14, 2017
Quoting: GuestFlatpak 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?
Dolus Sep 14, 2017
Quoting: GuestJokes 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.
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.