Thanks @cho-m! Can I get a sense of what this would enable/unblock for us to upgrade?

Thanks @cho-m! Can I get a sense of what this would enable/unblock for us to upgrade?

I mainly want to migrate to remove workarounds I added to use gcc@12 / llvm in

• node¹
• protobuf²
• or-tools³

This avoids an unnecessary dependency and Ubuntu's GCC may be faster.

GCC 12 should also allow us to bottle ada-url (and maybe use in node). And it should remove the gcc@12 usage in osrm-backend.

In terms of user impact:

• For users on bottles, there should be no noticeable impact. As mentioned in above thread, we have always used GCC 12 libraries
• For source-build users, those on OS like Ubuntu 22.04 and RHEL 9 could be impacted where the default [apt | dnf] install gcc is GCC 11 (EDIT: though compiler selection may still be able to pick GCC 11?). These should have workarounds available to avoid brew gcc@12:
  • Ubuntu 22.04 users can install g++-12 and then update-alternatives
  • RHEL/Centos/Rocky 9 users can dnf install gcc-toolset-12 and then alternatives it

@cho-m Thanks for explaining! As long as we can handle the from-bottle case automatically that'd be ideal. The from source case we may want a brew doctor warning for (but optional given it's not supported anyway).

It's also worth thinking here about when/whether we want to move to Ubuntu 24.04. I suspect the answer is "no, not yet" but we'll need to in ~1.5 years.

It's also worth thinking here about when/whether we want to move to Ubuntu 24.04. I suspect the answer is "no, not yet" but we'll need to in ~1.5 years.

No strong opinion here. Anytime from Apr 2026 (26.04 release date) to Apr 2027 (end of standard support) should be fine. May want to prepare advance notice to make sure users are aware of plan.

May want to prepare advance notice to make sure users are aware of plan.

We can communicate "at some point after X we will ...". We can't really commit to dates years out given a volunteer team 😭

Pushed some updates for review comments but will need to do more local testing to make sure they work.

We can communicate "at some point after X we will ...". We can't really commit to dates years out given a volunteer team 😭

Yeah, not a hard deadline. Just a rough timeframe as glibc upgrade can cause unexpected issues.

We can communicate "at some point after X we will ...". We can't really commit to dates years out given a volunteer team 😭

Yeah, not a hard deadline. Just a rough timeframe as glibc upgrade can cause unexpected issues.

@cho-m Agreed. Would you be able to pick up a first draft for this? Could be either in Support Tiers (there's similar stuff for macOS at the bottom) or Homebrew on Linux docs.

Container seems okay with quick build and formula install attempt. brew config shows:

Host glibc: 2.35
Host libstdc++: 6.0.30
/usr/bin/gcc-12: 12.3.0

Removing gcc-12 gives

Host glibc: 2.35
Host libstdc++: 6.0.30
/usr/bin/gcc: 11.4.0

Removing gcc gives

Host glibc: 2.35
Host libstdc++: 6.0.30
/usr/bin/gcc: N/A

Spun up a clean Rocky 9 container to see output:

OS: Rocky Linux release 9.3 (Blue Onyx)
Host glibc: 2.34
Host libstdc++: 6.0.29

And Ubuntu 16.04:

OS: Ubuntu 16.04.7 LTS
Host glibc: 2.23
Host libstdc++: 6.0.21

Can wait a couple days in case some issues show up for other commits. I will also try building formulae on docker image.

Should be ready to review. May want to wait for Tahoe bottling to slow down before merge so there is less CI activity.

Merging as Tahoe bottling has slowed down (first pass done, no bottle jobs) and GNOME formulae are starting to fail with GCC 11.

Can try to fix forward any failures we hit in Homebrew/core.