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

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.

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

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 :)

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.

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.

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.

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.

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.

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?

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.