Skip to content

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

Open
tannevaled wants to merge 3 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 3 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

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

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

Rebased onto main now that the gnu.org/gcc/v8 companion (pkgxdev#13733) has
merged — this PR is now a single-file recipe. MySQL 5.7's vendored InnoDB
uses pre-C++17 idioms that gcc 12+ rejects, so the linux build pins
gnu.org/gcc/v8; darwin uses the system clang. Runtime libstdc++ via
gnu.org/gcc/libstdcxx ^14 (forward-compatible with gcc 8's symbols).

Closes part of pkgxdev#99.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
tannevaled and others added 2 commits July 27, 2026 15:03
…appers)

With gcc/v8 pkgxdev#13770 merged, the compiler test passes, but the build then
used Clang, not gcc 8: brewkit's toolchain wrappers symlink cc/c++/gcc/g++
all to clang, so cmake auto-detected "Clang 22.1.8". MySQL 5.7's bundled
boost 1.59 then fails to compile (clang rejects boost mpl's
integral_wrapper.hpp non-type template usage) — the exact reason this
recipe pins gcc 8.

Point CMAKE_C_COMPILER/CMAKE_CXX_COMPILER straight at the gcc 8 bottle's
real binaries (absolute path, bypassing the wrappers). Darwin keeps using
system clang (matches homebrew's mysql@5.7). Verified on x86-64: cmake now
detects "GNU 8.5.0" and the boost 1.59 sources that failed under clang
compile cleanly with gcc 8.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
… 1.59

The macOS builders fail on the same boost 1.59 integral_wrapper.hpp error
as linux-with-clang did: MySQL 5.7's bundled boost needs gcc 8, but the
gcc/v8 bottle is linux-only (darwin's old-SDK situation makes gcc 8 hard
to bring up), so there's no viable darwin compiler for this legacy line.
The prior claim that macOS system clang builds mysql@5.7 fine is wrong.

Ship linux/x86-64 + linux/aarch64 (both build green with the forced gcc 8),
and drop the darwin platforms + darwin build branch.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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