Wine-Crossover as an alternative for wine-stable

1

Hello,

Reading the MonoGame setup documentation for MacOS it’s pointing to install wine-stable to allow fx compilation using DirectX.

During the installation there is a message advising that wine-stabe formula for homebrew will deprecate soon.

Warning: wine-stable has been deprecated because it does not pass the macOS Gatekeeper check! It will be disabled on 2026-09-01.

The question is if someone already tried to do this setup using wine-crossover for example and if the scrip worked fine.

Thank you.

2

Update: got this working, sharing the steps in case anyone else runs into the wine-stable deprecation.

The short version: CrossOver ships its own Wine build, but the wine command it puts on your PATH is not a drop-in replacement for stock Wine. It’s a wrapper that does CrossOver’s own “bottle” management and ignores WINEPREFIX, which is exactly what MGFXC (MonoGame’s effect compiler) needs. The actual Wine engine is a separate binary called wineloader, bundled inside CrossOver, and that one behaves like stock Wine. CrossOver also doesn’t ship a native winepath binary at all (the setup script needs one), only a Windows-side winepath.exe.

So the fix is two small wrapper scripts that point wine/winepath at CrossOver’s real engine instead of its bottle manager.

Steps (Apple Silicon / macOS):

  1. Install CrossOver from codeweavers.com instead of wine-stable (trial works fine for this).

  2. Find CrossOver’s real engine binaries. They’re inside the app bundle, not on PATH by default:
    find “/Applications/CrossOver.app” -iname ‘wineloader’ -o -iname ‘winepath.exe’
    (adjust the path if CrossOver is installed somewhere else, e.g. ~/Applications)

  3. Create two wrapper scripts that call the real engine directly:
    mkdir -p ~/.winemonogame-wrappers

cat > ~/.winemonogame-wrappers/wine <<‘EOF’
#!/bin/bash
exec “/Applications/CrossOver.app/Contents/SharedSupport/CrossOver/bin/wineloader” “$@”
EOF

cat > ~/.winemonogame-wrappers/winepath <<‘EOF’
#!/bin/bash
exec “/Applications/CrossOver.app/Contents/SharedSupport/CrossOver/bin/wineloader” “/Applications/CrossOver.app/Contents/SharedSupport/CrossOver/lib/wine/x86_64-windows/winepath.exe” “$@”
EOF

chmod +x ~/.winemonogame-wrappers/wine ~/.winemonogame-wrappers/winepath

  1. Run the official setup script with that folder added to PATH for just this command:
    curl -o mgfxc_wine_setup.sh https://monogame.net/downloads/net9_mgfxc_wine_setup.sh
    PATH=“$HOME/.winemonogame-wrappers:$PATH” bash mgfxc_wine_setup.sh

  2. When you actually build, wine/winepath need to be resolvable the same way. A few options, from simplest to cleanest:

    • Prefix the build command each time: PATH=“$HOME/.winemonogame-wrappers:$PATH” dotnet build
    • Add the folder to your shell profile’s PATH permanently. Simpler, but plain wine in any terminal will then use the raw engine instead of CrossOver’s bottle manager. Fine if you only use CrossOver for MonoGame, worth knowing if you also run other Windows apps through it from the CLI.
    • If your project builds content through your own MSBuild target (custom Exec calling dotnet run/mgcb, not the stock MonoGame.Content.Builder.Task package targets), you can set the PATH/MGFXC_WINE_PATH only on that Exec task with its EnvironmentVariables attribute. That scopes the fix to just that build step, no shell changes at all, and it works out of the box on Windows/Linux too since you can guard it with Condition=“$([MSBuild]::IsOSPlatform(‘OSX’))”.

Verify:
wine --version
winepath -w /tmp
wine --version should print something like wine-11.0-…

Hope this saves someone else the digging.

1 Like