Skip to content

new(mysql.com/v5_7): MySQL 5.7 legacy (Top 300 #735)#13062

Open
tannevaled wants to merge 9 commits into
pkgxdev:mainfrom
tannevaled:new/mysql-v5-7
Open

new(mysql.com/v5_7): MySQL 5.7 legacy (Top 300 #735)#13062
tannevaled wants to merge 9 commits into
pkgxdev:mainfrom
tannevaled:new/mysql-v5-7

Conversation

@tannevaled
Copy link
Copy Markdown
Contributor

EOL line still pinned by some legacy apps. Build expected to need CI iteration.

🤖 Generated with Claude Code

5.7 reached EOL 2023-10. Some legacy apps (Rails 5.x, legacy
WordPress, custom replication setups) still pin to it. CMake
policy version override applied for the vendored boost.

Closes part of pkgxdev#99 (holdout pkgxdev#735). Build expected
to need iteration — 5.7 + modern toolchain is rough.
@tannevaled tannevaled marked this pull request as draft May 29, 2026 13:41
@tannevaled
Copy link
Copy Markdown
Contributor Author

Draft — MySQL 5.7's vendored InnoDB has non-standard C++ idioms (unnamed scoped enums in univ.i:418) that gcc 12+ rejects:

storage/innobase/include/univ.i:418:33:
  error: unnamed scoped enum is not allowed

Same family of problems as cubefs/RocksDB (#13050): the C++ standard has tightened and old MySQL 5.7 needs either gcc 8 (not in pantry) or source patches across many files.

MySQL 5.7 has been EOL since Oct 2023; homebrew dropped its formula in 2024. The right call may be to mark this as 'not viable from-source' rather than spend more cycles patching.

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 tannevaled marked this pull request as ready for review May 29, 2026 13:56
@tannevaled
Copy link
Copy Markdown
Contributor Author

Reopened — using new gnu.org/gcc/v8 recipe (#13070) for the legacy InnoDB compile. Same approach as cubefs (#13050). Builds once #13070 lands.

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