Skip to content

CI: Add macOS development release.#3418

Merged
ratkosrb merged 1 commit into
vmangos:developmentfrom
mserajnik:add-macos-release
May 22, 2026
Merged

CI: Add macOS development release.#3418
ratkosrb merged 1 commit into
vmangos:developmentfrom
mserajnik:add-macos-release

Conversation

@mserajnik
Copy link
Copy Markdown
Contributor

🍰 Pullrequest

This adds a macOS development release (arm64-only / Apple silicon) similar to the existing Linux and Windows releases, as requested by @ratkosrb.

The release is built on macos-26 targeting macOS 26 (CMAKE_OSX_DEPLOYMENT_TARGET=26.0) and published as dev-macos-arm64-<sha>.tar.gz alongside the existing Linux and Windows assets on the latest tag.

As with the Linux release, the package is portable but not fully statically linked (macOS doesn't actually support fully static binaries; libSystem.dylib always stays dynamic). Instead, the package bundles non-system runtime libraries in lib/ and uses install_name_tool to rewrite install names and rpaths, so binaries under bin/ find the bundled libraries after extraction. Every Mach-O file is then ad-hoc signed (codesign --force --sign -) because install_name_tool rewrites invalidate any prior signature.

System libraries under /usr/lib/ (e.g. libc++.1.dylib, libSystem.B.dylib, libresolv.9.dylib) and /System/ are not bundled, so the archive is expected to work on Apple silicon Macs running macOS 26 or newer. Intel Macs are not supported (Apple is removing Intel support with macOS 27 anyway and I don't think complicating the workflow is worth it to add support for EOL Apple systems).

The build pins mysql-client@8.4 (MySQL LTS through 2032) rather than the rolling mysql-client formula because MySQL 9 removed the mysql_native_password authentication plugin that MariaDB still uses by default. MySQL 8.4 keeps it built into the client library, so MariaDB users can connect out of the box. openssl@3 is also pinned explicitly even though it's preinstalled on macos-26 today, so a future runner image change can't silently break the build. The same pins are mirrored into the macOS CI build so we actually validate the release configuration.

The workflow includes a small smoke test (which I can also remove if unwanted) that extracts the archive on the same runner, runs realmd --version and mangosd --version, and walks every Mach-O file with otool -L to flag any dependency that is not part of the bundle and isn't under /usr/lib/* or /System/*.

Tested end-to-end on my Mac:
image

Proof

  • None

Issues

  • None

How2Test

  1. Download the macOS archive from my fork's latest release (dev-macos-arm64-<sha>.tar.gz).
  2. Extract it and run from the archive root:
cd vmangos-macos-arm64
  1. Clear the quarantine flag (Only if macOS refuses to launch the binaries with a Gatekeeper warning, typically when the archive was downloaded via a browser)):
xattr -d -r com.apple.quarantine .
  1. Copy and edit the config files:
cp etc/realmd.conf.dist etc/realmd.conf
cp etc/mangosd.conf.dist etc/mangosd.conf
  1. Adjust DB credentials and other settings as required for your setup.
  2. Put extracted client data under the archive root, matching the default DataDir = "." (or put it elsewhere and adjust DataDir accordingly):
vmangos-macos-arm64/
  maps/
  mmaps/
  vmaps/
  5875/
    dbc/
  1. Start realmd and mangosd from the archive root:
./bin/realmd
./bin/mangosd

Todo / Checklist

  • Test if it actually works

@ratkosrb ratkosrb merged commit 01e4a75 into vmangos:development May 22, 2026
13 checks passed
@mserajnik mserajnik deleted the add-macos-release branch May 22, 2026 17:32
Stoabrogga pushed a commit to Stoabrogga/vmangos that referenced this pull request May 23, 2026
(cherry picked from commit 01e4a75)

Adapted to the fork
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.

2 participants