Skip to content

new(gnu.org/gcc/v8): GCC 8 for legacy C++ projects#13070

Open
tannevaled wants to merge 3 commits into
pkgxdev:mainfrom
tannevaled:new/gcc-v8
Open

new(gnu.org/gcc/v8): GCC 8 for legacy C++ projects#13070
tannevaled wants to merge 3 commits into
pkgxdev:mainfrom
tannevaled:new/gcc-v8

Conversation

@tannevaled
Copy link
Copy Markdown
Contributor

Summary

  • New recipe gnu.org/gcc/v8 — GCC 8.x line, parallel to the latest gnu.org/gcc recipe.
  • Many projects vendoring older C++ libraries (RocksDB 6.3.x in cubefs, InnoDB in MySQL 5.7, pre-C++17 codebases) hit gcc 12+'s stricter copy-ctor / std::atomic / std::pair-construction rules. They compile cleanly with gcc 8 (last default-C++14 major).
  • This recipe enables follow-ups like new(cubefs.io): CubeFS — cloud-native distributed storage (from source) #13050 (cubefs) and new(mysql.com/v5_7): MySQL 5.7 legacy (Top 300 #735) #13062 (mysql@5.7) to pin `gnu.org/gcc/v8: '*'` and compile their vendored old C++ from source — keeping the from-source promise without monkey-patching upstream sources.
  • Linux only. Darwin's old-SDK situation makes gcc 8 hard to bring up, and llvm.org clang covers legacy on darwin.

Why

`pkgx +gnu.org/gcc^8` currently returns `ResolveError` — no 8.x bottle exists. This PR adds the recipe so pantry CI builds and bottles gcc 8 for downstream legacy recipes.

Test plan

  • gcc 8.x builds on linux/x86-64 + linux/aarch64
  • `gcc --version` reports "pkgx GCC 8.x.x"
  • `gcc -dumpversion` starts with "8."
  • Downstream test: cubefs.io can build RocksDB 6.3.6 with this gcc

🤖 Generated with Claude Code

Many projects vendoring older C++ libraries (RocksDB 6.3.x in
cubefs, InnoDB in MySQL 5.7, pre-C++17 codebases) hit gcc 12+'s
stricter copy-ctor / atomic / std::pair-construction rules. They
compile cleanly with gcc 8 (last default-C++14 major) but couldn't
build in pantry without a 8.x bottle — pkgx CLI returns
"ResolveError" on `gnu.org/gcc^8`.

This recipe is a thin pin to the 8.x line, parallel to the main
gnu.org/gcc recipe. Linux only — darwin's old-SDK situation makes
gcc 8 hard to bring up there, and llvm.org clang covers legacy on
darwin anyway.

Enables follow-up: cubefs.io (pkgxdev#13050) and mysql.com/v5_7 (pkgxdev#13062)
can pin `gnu.org/gcc/v8: '*'` to compile their vendored old C++.
tannevaled added a commit to tannevaled/pantry that referenced this pull request May 31, 2026
mysql.com/v5_7 build-depends on gnu.org/gcc/v8 (linux only) for the
InnoDB pre-C++17 idioms. The v8 recipe lives on a separate open PR;
merging it here so CI can resolve the dep and bottle this PR.

If pkgxdev#13070 lands first, this merge is a no-op.
tannevaled added a commit to tannevaled/pantry that referenced this pull request May 31, 2026
Two related fixes after seeing CI fail with "pkg not found:
gnu.org/gcc/v8" on darwin/aarch64 (29s, before any compile):

1. **gcc/v8 is linux-only**. The companion PR pkgxdev#13070 ships
   gnu.org/gcc/v8 with `platforms: [linux/x86-64, linux/aarch64]`
   only. The previous recipe declared it as a top-level build dep,
   which pkg resolver tried to satisfy on every platform — hence
   the not-found on darwin. Move the pin under `linux:`. On darwin
   we follow homebrew's mysql@5.7 lead (the deprecated formula at
   homebrew-core@44d961a18 — last 5.7.43 commit before deletion):
   no gcc pin, the system clang compiles 5.7's vendored InnoDB
   fine.

2. **Runtime libstdcxx pin**. Same lesson as the main mysql recipe
   in PR pkgxdev#13104: pantry doesn't auto-propagate stdenv.cc.cc.lib
   into RUNPATH the way nixpkgs does, so the runtime
   libstdc++.so.6 must be declared explicitly. gcc 8 emits
   GLIBCXX_3.4.25-ish symver references, which the forward-
   compatible libstdcxx ^14 satisfies (older symver references
   resolve against newer libstdc++).

3. **Drop -DCMAKE_CXX_STANDARD=17**. Pinning gcc 8 is precisely to
   accommodate 5.7's pre-C++17 vendored InnoDB; forcing C++17 on
   top defeats the point. homebrew's mysql@5.7 doesn't set
   CXX_STANDARD at all — gcc 8's default (gnu++14) is correct.

Also merged the gnu.org/gcc/v8 recipe from pkgxdev#13070 into this branch
so CI can resolve the dep without waiting for that PR to land.
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.

1 participant