Support us on Patreon to keep GamingOnLinux alive. This ensures all of our main content remains free for everyone with no article paywalls. Just good, fresh content! Alternatively, you can donate through PayPal or Buy us a Coffee. You can also buy games using our partner links for GOG and Humble Store.
We do often include affiliate links to earn us some pennies. See more here.

Recently it was noticed that users on more bleeding-edge Linux distributions that updated saw Easy Anti-Cheat no longer working on Linux, the culprit was glibc and now a Valve developer has spoken out about it.

Writing in a small thread on Twitter, Valve developer Pierre-Loup Griffais said:

Unfortunate that upstream glibc discussion on DT_HASH isn't coming out strongly in favor of prioritizing compatibility with pre-existing applications. Every such instance contributes to damaging the idea of desktop Linux as a viable target for third-party developers.

Our thoughts on the topic from this prior compatibility issue in BlueZ apply more than ever: https://github.com/bluez/bluez/commit/35a2c50437cca4d26ac6537ce3a964bb509c9b62#commitcomment-56028543
It is unfortunately yet another entry in a growing list over the years.

We understand that working with a focus on compatibility requires more resources and more engineering trade-offs, but strongly believe it is nonetheless the way to go. We are very interested in helping with any underlying resource constraints.

This prompted CodeWeavers (who work on Wine and with Valve on Proton) developer Arek Hiler to write a blog post titled "Win32 Is The Only Stable ABI on Linux" and their ending statement is something people should think on:

I think this whole situation shows why creating native games for Linux is challenging. It’s hard to blame developers for targeting Windows and relying on Wine + friends. It’s just much more stable and much less likely to break and stay broken.

Hiler certainly isn't the only one to think like that, with another CodeWeavers developer Andrew Eikum mentioning on Hacker News some time ago:

As a long-time Linux dev (see my profile), I have also found this to be true. Linux userland APIs are unstable and change all the time. Some transitions that come to mind that have affected me personally: ALSA->pulse; libudev->libudev2->systemd; gstreamer 0.10->1.0. All of those changes required modifications to my software, and the backwards-compat tools that are provided are buggy and insufficient. Meanwhile, you can still write and run winmm[1] applications on Windows 10, and they will work in almost all cases. It's simply the case that the win32 API is more stable than Linux userland APIs, so it's entirely plausible that games will run better in Wine, which shares that stable ABI, than they will on Linux, especially as time goes on and Linux userland shifts yet again.

[1] winmm dates to the Windows 3.x days!

Situations like this can be pretty messy and this is not a case of open source versus secret closed source anti-cheat stuff either, since the glibc issue affected a Native Linux game (Shovel Knight) and Linux software libstrangle. No doubt there are other things yet to be discovered that were broken by the change.

It is of course also a case that Linux distributions need to ensure they do quality assurance testing, especially for gaming which can end up showing up issues quite easily and that bleeding-edge distributions can and clearly do end up breaking things by pulling new software in so quickly.

Article taken from GamingOnLinux.com.
43 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.
See more from me
123 comments
Page: «12/13»
  Go to:

F.Ultra 18 Aug
View PC info
  • Supporter
Quoting: Eike
Quoting: F.Ultra
Quoting: JordanPlayz158
Quoting: minidouI fail to see how glibc devs could be blamed for removing a function deprecated for 17 years (though I can agree a major version bump should have been called for). Do videogame devs need that much nursing ? EAC linux lib is a recent piece of software, how many deprecated dependencies do they use ?
Quoting: TermyI tend to agree with the criticism about unstable APIs for many cases - but in this case, i really blame Epic for using a function deprecated for almost two decades in a recent piece of software.
From everything I've read from other people, it wasn't obvious that the function was depreciated. You shouldn't need to search up, "is x function depreciated glibc" for every function you use, it should be immediately obvious (like most languages I know have comments or a depreciation tag), some say that all distros somehow knew about this but you shouldn't need to be familiar with linux development or need to be in the right communities to know about a depreciated function.

Small nitpick here, but DT_HASH is not a libc function, it's a linker section in the ELF header of a shared object. The function that utilizes this section is dlopen() and that function have not changed and it works, it's only applications that tries to read the ELF data manually that have to handle DT_HASH and DT_GNU_HASH, and by all means it looks like the glibc devs "incorrectly" thought that dlopen was their ABI/API and not the actual linker section in the ELF headers.

I find this neither nitpcking nor small! So it isn't an actual API change, but considered an internal data invisible to almost every user program.

Well it's complicated :). The glibc devs obviously didn't consider this a part of their API/ABI (they might do so going forward however) of their library. On the other hand ELF itself can from a point of view be considered to be the ABI of a shared object.

99.99999% of all applications does not care one cent about any of the ELF headers, all the work of parsing out the data to be used is handled by the libc functions such as dlopen() but some special applications, and EAC does match this criteria, wants to read/write and parse the ELF data directly and not use any of the provided libc functions. For EAC they do this in case dlopen() have been patched under their nose to hide the fact that this .so loads a cheating mod.

The problem here then is that the official ELF spec only contains DH_HASH and then have some mumble mumble about possible extensions while glibc back in 2005/2006 introduced DH_GNU_HASH as the better alternative. The official ELF specs does not carry "vendor extensions" AFAIK, of which this is one, and the glibc devs didn't really care either since they made sure that gcc and ld could handle both (and later clang, musl etc implemented the very same since they saw that gcc and ld handled this extension).

So we can't really blame the EAC devs either more to the point that they should perhaps have not just read the specs but also taken a look at how the actual implementation (gcc+ld) works since ELF can have extensions and as I wrote earlier I wonder if this could open a potential hole in the current implementation of EAC where a maleficent .so creates a nice looking DH_HASH while hiding their real stuff in DH_GNU_HASH since EAC only looks at the first while ld loads the second (but I'm not intimate enough with the exact details here to know for sure, perhaps ld loads only used DH_GNU_HASH if DH_HASH isn't there or EAC loads the .so for the game so that ld isn't involved at all).

What I do think that we can blame is all the people that scream bloody murder, I mean yes it was a problem, but it was fixed and it was fixed quickly. That last part is IMHO the important part and what makes Linux really shine, so to me this should be seen more as a positive thing and not as the horrible negative thing that it have became.
CyborgZeta 18 Aug
Thank for the responses to my earlier question.

Can I just give credit to the Arch Linux developers/maintainers for quickly spotting this issue and patching it? They sure handled this promptly.
So an employee from a company who makes a closed source game store client that hosts a closed source game that uses closed source anticheat software had an issue with an open source library and i'm supposed to side with the employee ? Do I about have that right ? Would it not be an easier issue to fix if more of that equation I listed were open source ?
shorberg 19 Aug
View PC info
  • Supporter Plus
Quoting: dibzI appreciate the explanations. Though, my use of "Borderline Autistic" is actually close to home for me. Without airing my laundry on the internet, I will say that I used the term in the context that I learned it in the first place -- in a healthcare setting when diagnosing one of my children who I could absolutely see being a "strongly opinionated linux user" like many of us, heh.

Fair!

If you feel it appropriate and you think your child would like it, say "Hi!" from me. You do not have to state your decision on this on the public forum.
Quoting: PublicNuisanceSo an employee from a company who makes a closed source game store client that hosts a closed source game that uses closed source anticheat software had an issue with an open source library and i'm supposed to side with the employee ? Do I about have that right ? Would it not be an easier issue to fix if more of that equation I listed were open source ?
It wasn't just EAC that broke but a few other applications like Shovel Knight, a game with a native linux port and libstrangle, an fps limiting library, this isn't about open vs closed source software, this is about maintaining backwards compatibility to not only make linux more enticing to port to but also to make it so things like games that do not get maintained forever won't get lost to time.
slaapliedje 19 Aug
View PC info
  • Supporter Plus
Quoting: JordanPlayz158
Quoting: PublicNuisanceSo an employee from a company who makes a closed source game store client that hosts a closed source game that uses closed source anticheat software had an issue with an open source library and i'm supposed to side with the employee ? Do I about have that right ? Would it not be an easier issue to fix if more of that equation I listed were open source ?
It wasn't just EAC that broke but a few other applications like Shovel Knight, a game with a native linux port and libstrangle, an fps limiting library, this isn't about open vs closed source software, this is about maintaining backwards compatibility to not only make linux more enticing to port to but also to make it so things like games that do not get maintained forever won't get lost to time.
Well, it 'sort of' is about open vs closed. If it was open (Shovel Knight) someone could have given them a pull request to change to the newer method. That's pretty straight forward.

This wasn't really about backward compatibility, and more about deprecated methods still being used in software. This should be a wake up call for those projects that use old crappy code, and hopefully they'll get updated to be faster.
Quoting: slaapliedje
Quoting: JordanPlayz158
Quoting: PublicNuisanceSo an employee from a company who makes a closed source game store client that hosts a closed source game that uses closed source anticheat software had an issue with an open source library and i'm supposed to side with the employee ? Do I about have that right ? Would it not be an easier issue to fix if more of that equation I listed were open source ?
It wasn't just EAC that broke but a few other applications like Shovel Knight, a game with a native linux port and libstrangle, an fps limiting library, this isn't about open vs closed source software, this is about maintaining backwards compatibility to not only make linux more enticing to port to but also to make it so things like games that do not get maintained forever won't get lost to time.
Well, it 'sort of' is about open vs closed. If it was open (Shovel Knight) someone could have given them a pull request to change to the newer method. That's pretty straight forward.

This wasn't really about backward compatibility, and more about deprecated methods still being used in software. This should be a wake up call for those projects that use old crappy code, and hopefully they'll get updated to be faster.
We'll have to agree to disagree on that front, most of the outrage I've seen is about glibc developers not making it clear they were removing DT_HASH (and that you needed to go to mailing lists and such to know it was depreciated, incremented the patch rather than the major for a breaking change) and I'd say the bigger deal of hurting the prospect of the Linux desktop being ported to or getting more native applications (especially for game developers when games inevitably stop getting maintained and typically do not get their source released once the game is EOL) due to these sort of changes
STiAT 19 Aug
Quoting: JordanPlayz158
Quoting: slaapliedje
Quoting: JordanPlayz158
Quoting: PublicNuisanceSo an employee from a company who makes a closed source game store client that hosts a closed source game that uses closed source anticheat software had an issue with an open source library and i'm supposed to side with the employee ? Do I about have that right ? Would it not be an easier issue to fix if more of that equation I listed were open source ?
It wasn't just EAC that broke but a few other applications like Shovel Knight, a game with a native linux port and libstrangle, an fps limiting library, this isn't about open vs closed source software, this is about maintaining backwards compatibility to not only make linux more enticing to port to but also to make it so things like games that do not get maintained forever won't get lost to time.
Well, it 'sort of' is about open vs closed. If it was open (Shovel Knight) someone could have given them a pull request to change to the newer method. That's pretty straight forward.

This wasn't really about backward compatibility, and more about deprecated methods still being used in software. This should be a wake up call for those projects that use old crappy code, and hopefully they'll get updated to be faster.
We'll have to agree to disagree on that front, most of the outrage I've seen is about glibc developers not making it clear they were removing DT_HASH (and that you needed to go to mailing lists and such to know it was depreciated, incremented the patch rather than the major for a breaking change) and I'd say the bigger deal of hurting the prospect of the Linux desktop being ported to or getting more native applications (especially for game developers when games inevitably stop getting maintained and typically do not get their source released once the game is EOL) due to these sort of changes

This was certainly a documentation mistake, but as well misunderstanding what they (glibc) consider as their api/abi, and what some applications did consider by it.

That said, it should have been a wakeup call to those using it, and we will probably see ports to DT_GNU_HASH, and DT_HASH will disappear with a major release at some point.

That will give them thoughts about what they want to deprecate of the ELF sections too for a next major release. And it's good this process started.

It's a real nieche usage, I personally never did require to use DT_HASH or DT_GNU_HASH since dlopen pretty much did work for my cases. But I undetstand wanting to directly read library information in some use cases (security scanners being one, they certainly don't want something messing with dlopen, and I know some commercial tools messing with the dlopen and generally library loading process, dynatrace comes to mind as an example).


Last edited by STiAT on 19 August 2022 at 7:00 pm UTC
Kuduzkehpan 19 Aug
Print("""
no native computing?
still no?
why should we expect rather than this?
""")
native = input("Native Computing Or not Choose wisely and case sensitive")
if native != "Native Computing":
print("you deserved that")
else
print("Finally May the open source be with you")
Klaas 19 Aug
Quoting: Kuduzkehpanelse
SyntaxError: expected ':'
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 with no article paywalls. We also don't have tons of adverts, there's also no tracking and we respect your privacy. Just 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!
Login / Register

Or login with...
Sign in with Steam Sign in with Twitter Sign in with Google
Social logins require cookies to stay logged in.