Re: gcc: update to 12.2.0.

[TeusLollo <TeusLollo@users.noreply.github.com>]

[-- Attachment #1: Type: text/plain, Size: 6806 bytes --]

New comment by TeusLollo on void-packages repository

https://github.com/void-linux/void-packages/pull/34902#issuecomment-1256992328

Comment:
> And therein lies the rub, right? The ideal solution would be for EAC to be updated, but that just isn't gonna happen. Perhaps even worse, some games using EAC may be done updating permanently, and depending on how they built/linked EAC, they may _never_ incorporate this hypothetical upgrade. In other words, Steam in Flatpak might be the only effective, permanent solution to this bug… which drives me nuts, because I'm stubborn and I won't touch Flatpak with a 10 ft pole if I can help it

**As I said, I'm not trying to be dismissive of the problem. But look at this:**

_Did glibc 2.36 need a release note about dropped -Wl,--hash-style=both? Game users affected by the problem might argue that this was a high profile change and a deprecation or warning notice was needed. I disagree.
I beg that you read Carlos's summary. DT_HASH is a protocol between a linker and a dynamic loader. It is not intended to be consumed by a random non-standard ELF consumer. In addition, 16 years have been sufficiently long for any non-standard ELF consumer to know that DT_HASH has been mostly eliminated from Linux distributions. The glibc change removed one remnant DT_HASH use. It really was not as impactful as other changes in glibc 2.36._

**16 YEARS in deprecation. 
And what's more, is that's now even a proper ABI component, more of an ABI detail whatsoever:**

_Is DT_HASH optional in the generic ABI?_

_If one reads much from the generic ABI wording, it says "mandatory", and therefore it is not optional. Does this make sense?_

_Technically a dynamic loader does not need a hash table to perform symbol lookup. It can start at the dynamic symbol table beginning specified by DT_SYMTAB, and scan to the end. Wait, in the absence of DT_HASH (DT_GNU_HASH is an extension, we want a way without an extension), there is no reliable way to get the number of dynamic symbol table entries. I tend to think this is outside of the generic ABI's business to require something. An ELF object can freely use an extension to provide the information. Specifying things in such a verbatim way is not ELF's spirit. Michael Matz disagrees in a [reply](https://groups.google.com/g/generic-abi/c/th5919osPAQ/m/uGSA05KIAgAJ) to "Making DT_HASH optional?"._

**Source :** https://maskray.me/blog/2022-08-21-glibc-and-dt-gnu-hash

I don't think glibc developers were in the wrong here. There was plenty of time to dismiss deprecated code segments. In fact, had they done this before, none of that would have happened at this scale. 

But, do we really want to shift the burden of maintenance from giant entertainment companies who really should be doing due to their own financial interests, to mostly volunteer-run distros which now should either hold back upgrades, or otherwise fork the glibc to patch-in ancient code segments deprecated since decades? I know the Linux market segment is abysmal in the video-game department, but we're still talking about companies with giant revenues, who apparently don't want to hire a college graduate for a week/month to fix very simple problems on time. 

Maybe we could use xbps-alternatives to import and package from whoever will be doing the patching on the glibc 2.36 with such a "legacy" component, and whoever needs the patched glibc package, uses that, while the rest resides into the "vanilla" glibc 2.36? Not very elegant, and probably prone to breakage, but it still requires a maintainer on the Void Linux side.  

Or maybe the Proton devs will come up with a shim of sort? Sounds really like their thing, after all. 
Or maybe the Steam-client could finally be recompiled in a 64-bit x86_64 architecture, and packaged into a decent AppImage? I mean, they bothered with Flatpak, why not AppImage? Licensing issues, I presume?

**All I'm saying is, the problem is downstream. VERY downstream.** 
Holding back the glibc upgrades now (And probably further future upgrades next year, by the looks of it, since who should be doing it does not seem to care about updating their EAC software) will just multiply concerns for Void Linux maintainers who do this for free. 

Who knows what will happen next year on the gcc, and how it may react with the older glibc 2.35 if we get stuck on that because of EAC woes? What further software will break and will need dedicated patching? What if it stresses Void Linux maintainers too much, and sends the whole distro in a downward spiral? And lastly, do we really want to force ALL users to stick on the glibc 2.35, and deprive them of increased performance and security benefits which the glibc 2.36 provides? All because ONE company refuses to upgrade a VERY DOWNSTREAM piece of software?

I'm pleased to see gaming on Linux, and on Void Linux particularly (I mean, gaming beyond the good old DOOM sourceports and the like). But in this case, holding back feels like it could damage the entire distro. We're already a bit behind (Not by much, but still) on gcc/glibc upgrades for a "rolling", albeit "stable", distro. See how much work has been required, on this very thread, to update the gcc/glibc. Do we want to throw out all of those efforts because a giant company refuses to update software it should update, in their very interests to do so?

Gaming, or more like, "Mainstream" gaming on Linux is clearly still on its infancy, and although it has been making giant leaps in the past 5 years (Thanks to Valve, that should be admitted), it still has ways to go, clearly. 

For now, I indicated the usage of Flatpak (Which neither myself like, mind you, ESPECIALLY with the Steam-client) which appears to be a functional if cumbersome workaround. Maybe an AppImage would work even better, assuming it can be assembled at all due to licensing requirements?

But, the work on the gcc/glibc upgrades should continue, regardless. We can't just throw out all those efforts now, and further risk multiple headaches and performance/security concerns down the line on ALL software for ALL users, just because ONE company refuses to update their entertainment products. 

You're very welcome to say that I probably am concerned about the glibc 2.36 update because of personal reasons (Which is true, albeit marginally so for now), but I still stand by the wall of text above that I have indicated objective arguments. 

**I believe we should find workarounds to the EAC problem, but work on the gcc/glibc updating should continue undisturbed to the benefit of ALL users, due to maintainability, performance, and security concerns solved by the glibc 2.36 update, while sticking with glibc 2.35 instead would be detrimental to the entire distro.**