gcc: update to 12.1.0

[oreo639]

[ci skip]

Edit: this PR had been updated for gcc 12.1.0

This PR depends on: https://github.com/void-linux/void-packages/pull/32330

I tested this PR with glibc and after updating glibc, it seems to work fine. I also tested this PR with x86_64-musl, and it appears to run fine in a musl chroot, and recompiling and installing musl with gcc 12 doesn't appear to result in any issues. (more testing is needed)

Please let me know if there are any issues.

I compiled base-system to ensure that compiles and it appears to work fine.

Testing the changes

• I tested the changes in this PR: briefly

Local build testing

• I built this PR locally for my native architecture, (x86_64-glibc)
• I built this PR locally for these architectures (if supported. mark crossbuilds):
  • x86_64-musl

[dkwo]

I was getting a bunch of WARNING: usr/lib/*.so should be in -devel package as well as

=> WARNING: libada-11.2.1git20211128_1: libgnarl-11.so not found in common/shlibs!
=> WARNING: libada-11.2.1git20211128_1: libgnat-11.so not found in common/shlibs!
=> WARNING: gcc-11.2.1git20211128_1: libcp1plugin.so.0 not found in common/shlibs!

[oreo639]

=> WARNING: libada-11.2.1git20211128_1: libgnarl-11.so not found in common/shlibs! => WARNING: libada-11.2.1git20211128_1: libgnat-11.so not found in common/shlibs!

Thank you for pointing that out, fixed.

=> WARNING: gcc-11.2.1git20211128_1: libcp1plugin.so.0 not found in common/shlibs!

libcp1plugin.so.0 is in the current gcc 10 package and isn't in shlibs, so I assume that isn't an issue since nothing depends on it.

Same for all of the WARNING: usr/lib/*.so should be in -devel package afaict, so unless the maintainers think it is an issue, it probably isn't a big deal.

[lane-core]

@oreo639 is there any way that I can assist this effort?

[oreo639]

Not that I am aware of at the moment. If the maintainers want me to make any changes they can let me know. If they want to use it as a reference for their own gcc 11.2 port, they can do so.

[github-actions[bot]]

Pull Requests become stale 90 days after last activity and are closed 14 days after that. If this pull request is still relevant bump it or assign it.

[motorto]

@oreo639: could you bump this so that this work isn't lost ? I will try to build on my x86_64-musl system and report back.

And maybe bump to 12.1.0 ?

[lane-core]

👀 🥇

[oreo639]

I built all of the glibc isos so hopefully most of those major breakages are accounted for, I also provided isos fully compiled using gcc12 for testing purposes. Feel free to test this PR on musl if you want to and let me know if there are any issues there.

Ofc any feedback is appreciated.

[dkwo]

Would it be possible to bump the minor version to 12.2?

[dkwo]

This is what I get for libtool on x86_64-musl:

ERROR: 137 tests were run,                                                                                                                                     
7 failed (5 expected failures).                                                                                                                                
32 tests were skipped. 

 69: shlibpath_overrides_runpath                     FAILED (shlibpath.at:69)
169: Run tests with low max_cmd_len                  FAILED (cmdline_wrap.at:48)

[oreo639]

@dkwo

This is what I get for libtool on x86_64-musl:

Those failures existed before this PR, but thank you for pointing that out. It has to do with whether or not LD_LIBRARY_PATH overrides RPATH, which on glibc it doesn't but on musl it does, libtool has a flag for that but it is still set to shlibpath_overrides_runpath=no on musl, not sure if that is correct or not.

[dkwo]

I see, thanks for pointig out. Indeed, also Alpine has

check() {
	# Test 69 shlibpath_overrides_runpath fails
	# Test 169 repeats the entire test suite with shorter max_cmd_len
	make check TESTSUITEFLAGS="1-68 70-168"
}

[oreo639]

Indeed, also Alpine has

It should be fixed with lt_cv_shlibpath_overrides_runpath=yes. Thanks.

[leahneukirchen]

The musl cross compilers use glibc now, something is wrong in your patchset.

[dkwo]

Could you perhaps rebase? Does it cross-compile right now?

[oreo639]

Does it cross-compile right now?

Wdym? If you are compiling the cross compilers, you cannot have the cross compilers installed in your masterdir if that is what you are asking?

Edit: Oh, you're probably talking about what Leah said. We discussed it on IRC, it was a copy-paste error on some of the mips/ppc cross compilers. I double checked them so they should all be fixed now, ofc feel free to double check.

[f3rvi]

I've tried installing gpgme from your fork and I got "cross-vpkg-dummy conflct" or something like that? Is that intended to be like that?

[oreo639]

I don't installing gpgme from this PR (the propper PR is linked in the original post, it's just duplicated here to fix a build failures experienced when building the ISOs fully from source).

The full error and command used would be helpful. (also, you can always try deleting your masterdir and running ./xbps-src binary-bootstrap to re-create it if things get messed up)

[TeusLollo]

Excellent. Thanks for your work, Mr. Oreo639! And also thanks to the rest of the Void gang!

BTW, I believe the title should mention that this PR is related to both the latest of gcc and glibc. This because, as it is, this PR is kinda buried, and I couldn't find much about an update to the latest glibc until those recent commits started flocking in.

Also, maybe a milestone somewhere would also be useful, since on reddit users have been asking for glibc updates since weeks by now, and they clearly haven't found this.

This is mostly cosmetic of course, so take my mostly-useless advice with a pinch of salt.

Again, thanks!

[f3rvi]

About gpgme - yes, that's my fault.

But I now I've tried compiling gcc and getting this at comparing stage 2 and 3:

..... (many other "differs") mpfr/src/set_si.o differs make[2]: *** [Makefile:32435: compare] Error1 make[1]: *** [Makefile:32415: stage3-bubble] Error 2 make[1]: Leaving directory '/builddir/gcc-12.2.0/build make: *** [Makefile:1081: all] Error 2 => ERROR: gcc-12.2.0_1: do_build: 'make ${makejobs}' exited with 2 => ERROR: in do_build() at srcpkgs/gcc/template:324

I used ./xbps-src binary-bootstrap, and then ./xbps-src pkg gcc. Anything I can do without completely recompiling again?

[oreo639]

Can you paste the whole output into a gist (feel free to run the command again). (Also if you didn't previously, you should make sure you deleted your masterdir/builddir after running binary bootstrap to make sure there aren't any leftover files from a non-chroot build)

[f3rvi]

https://gist.github.com/xfervi/840e1d0fc948128eac6ec7563f60698f Here it is. Also, there is no dirs in builddir except for gcc, gmp, isl, mpc and mpfr.

[oreo639]

Also, there is no dirs in builddir except for gcc, gmp, isl, mpc and mpfr.

Yes, I'm saying to delete them and try to build it again. (also delete the .xbps-gcc folder)

Also, you can do ./xbps-src pkg -jN gcc to do a multithreadded build (with N being the max number of processes).

[f3rvi]

Ah sure... I'll try building again. Thanks for tip btw, as previous build took around 15 hours.

[f3rvi]

I'm not sure how, but recompiling fixed that. Thanks!

[Seltyk]

glibc 2.36 removes DT_HASH which breaks Easy Anti-Cheat (see this Proton issue or this Phoronix article for more info). I don't think I have any games with that, but I can't be the only person who games on Void, so certainly this PR will cause issues for at least one person. What can be done to prevent this issue? I see two options: glibc could be held at 2.35, or patches could be used to reintroduce DT_HASH (but I doubt anybody wants to be the poor soul maintaining that). glibc 2.35 is recent enough to use R2Northstar (which requires 2.33+) but old enough to play EAC games.

[oreo639]

glibc 2.36 removes DT_HASH which breaks Easy Anti-Cheat

I couldn't get an EAC game to work on Void with glibc 2.32 so whatever. If it affects someone, they can say so.

but I doubt anybody wants to be the poor soul maintaining that

It's just a linker flag. That being said, it's a bug that EAC expects sysv-style hashes in glibc binaries when most distros configure bfd/binutils to only use gnu-style hashes.

Edit: my point was that I see no reason in working around an issue for a piece of software if it doesn't support Void, that's it.

[TeusLollo]

I agree with oreo639. It's a bug in EAC, and they are supposed to fix it (I know, I know, they never do in practice).

https://github.com/ValveSoftware/Proton/issues/6051#issuecomment-1204399354 They also say here to utilize Steam in Flatpak to work-around this issue, which may help?

I would say to continue working working on the glibc update (Which will still take a while, anyway). I'm already having trouble with some compiling explicitly requiring glibc 2.36 only.

Maybe in the meantime upstream glibc will do something, or maybe someone at Proton will come up with a shim/wrapper of some sort?

Mind you, I'm not dismissing this problem in any way (I'm sorry if I came out sounding like that), I just think those changes in glibc 2.36 were justified, and that in general Void should not be stuck on an older glibc version due to potential compatibility problems emerging (Which I personally I'm already encountering on some private repos).

[Seltyk]

It's just a linker flag. That being said, it's a bug that EAC expects sysv-style hashes in glibc binaries

Well, learned something new today.

they [Epic] are supposed to fix it (I know, I know, they never do in practice)

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

[TeusLollo]

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