Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gcc: update to 12.2.0. #34902

Closed
wants to merge 38 commits into from
Closed

gcc: update to 12.2.0. #34902

wants to merge 38 commits into from

Conversation

oreo639
Copy link
Member

@oreo639 oreo639 commented Jan 6, 2022

[ci skip]

Edit: this PR had been updated for gcc 12.2.0

There are lists of failing builds here: #39809, #39960

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 and base-chroot on x86_64-glibc and x86_64-musl to ensure that compiles and it appears to work fine.

I tested some of the cross compilers and after some debugging with the help of CameronNemo, we figured out the issue.
The cross compilers are built with nopie=yes (specified in environment/build-style), which causes issues with glibc 2.35+ which uses PIE by default.
gcc always builds itself as nopie.
I added a workaround to common/build-style/void-cross but if you have any other recommendations on how to handle it, feel free to let me know.

This PR also updates glibc to 2.36:
https://sourceware.org/glibc/wiki/Release/2.36

Necessary to fix previously existing build failures (unrelated to this PR):

Known packages that need to be fixed/updated for glibc 2.36:

Known packages that needed to be fixed/updated for gcc12:

Needs to be fixed/updated for binutils:

ISO packages verified:

  • base system
  • base chroot
  • gnome
  • xfce
  • mate
  • cinnamon
  • enlightenment
  • kde
  • lxde
  • lxqt

You can test the ISOs here:
https://drive.google.com/drive/folders/1ix92CYSLUP-KWjLxltdgG4e8Nu2JCY5n?usp=sharing

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
Copy link
Contributor

dkwo commented Jan 26, 2022

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
Copy link
Member Author

oreo639 commented Jan 26, 2022

=> 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
Copy link
Contributor

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

@oreo639
Copy link
Member Author

oreo639 commented Feb 17, 2022

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
Copy link

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.

@github-actions github-actions bot added the Stale label Jul 14, 2022
@motorto
Copy link
Contributor

motorto commented Jul 17, 2022

@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 ?

@github-actions github-actions bot removed the Stale label Jul 18, 2022
@oreo639 oreo639 marked this pull request as draft August 12, 2022 13:29
@oreo639 oreo639 changed the title gcc: update to 11.2.1git20211128 gcc: update to 12.1.0 Aug 12, 2022
@oreo639 oreo639 force-pushed the gcc11 branch 8 times, most recently from 4c0ca83 to cc0fc1f Compare August 15, 2022 08:20
@lane-core
Copy link
Contributor

👀 🥇

@sug0
Copy link
Contributor

sug0 commented Dec 15, 2022

Thank you for your hard work! Looks like the patchset can be used to build a gcc 12 toolchain now. Any current blockers on the merge?

@sgn sgn closed this in 6644d4c Dec 17, 2022
@oreo639 oreo639 deleted the gcc11 branch December 18, 2022 05:00
akierig pushed a commit to akierig/void-packages that referenced this pull request Dec 18, 2022
@lane-core
Copy link
Contributor

what a nice surprise running xbps-install -Su today, thank you for all the hard work @oreo639!!

@oreo639
Copy link
Member Author

oreo639 commented Dec 20, 2022

Np. Also, thank you paper42, sgn, leahneukirchen, and Johnnynator.

@TeusLollo
Copy link

Indeed. Thanks to @oreo639 and to the rest of the gang.

By the next gcc/glibc update, I hope I'll be knowledgeable enough of the xbps build system to help at least with testing/pull requests (Still too much of a newbie at distro maintenance, for now I'm mostly a bug reporter/fix identifier)

bootstrap=yes
short_desc="GNU C library"
maintainer="Enno Boland <gottox@voidlinux.org>"
license="GPL-2.0-or-later, LGPL-2.1-or-later, BSD-3-Clause"
homepage="http://www.gnu.org/software/libc"
distfiles="${GNU_SITE}/glibc/glibc-${version}.tar.xz"
checksum=1627ea54f5a1a8467032563393e0901077626dc66f37f10ee6363bb722222836
distfiles="https://vasilek.cz/paste/glibc-${version}-${_patchver}.tar.xz"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why was this done?

Copy link
Member Author

@oreo639 oreo639 Jan 5, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

glibc has a release branch where patches go to including several critical ones.
https://github.com/bminor/glibc/tree/release/2.36/master
paper didn't want me to include the branch as a patch (like what debian does) since the patch is enormous.
So we generated a tarball from the release branch using make dist. (Fedora does this and Arch just uses git)
It was generated from the following commit:
bminor/glibc@0f90d62

The patchver is the output of git describe: <ncommit>-g<commit-hash>
Where ncommit is the number of commits between the release branch and the release tag.

It was also supposed to get uploaded to https://repo-default.voidlinux.org/distfiles/ but no one has done that yet so it is still pointing to paper's server.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet