LizardByte
macOS compilation failure
Is there an existing issue for this?
- [x] I have searched the existing issues
Is your issue described in the documentation?
- [x] I have read the documentation
Is your issue present in the latest beta/pre-release?
This issue is present in the latest pre-release
Describe the Bug
sunshine-beta failed to build on MacBook Air M2
Expected Behavior
The build should be successful.
Additional Context
MacBook Air M2 macOS 15.5 (24F74)
Host Operating System
macOS
Operating System Version
macOS 15.5 (24F74)
Architecture
arm64/aarch64
Sunshine commit or version
2025.617.220707
Package
macOS - Homebrew
GPU Type
Apple Silicon
GPU Model
M2
GPU Driver/Mesa Version
macOS 15.5 (24F74)
Capture Method
None
Config
Apps
Relevant log output
==> Installing sunshine-beta from lizardbyte/homebrew
==> Building docs: disabled
==> Disabled statically linking Boost libraries
==> make INSTALLPREFIX=/opt/homebrew/Cellar/sunshine-beta/2025.617.220707/miniupnpc
==> cmake -S . -B build -G Unix Makefiles -DBUILD_WERROR=ON -DCMAKE_CXX_STANDARD=20
==> make -C build
Last 15 lines from /Users/UserName/Library/Logs/Homebrew/sunshine-beta/03.make:
"_X509_set_version", referenced from:
crypto::gen_creds(std::__1::basic_string_view<char, std::__1::char_traits<char>> const&, unsigned int) in crypto.cpp.o
"_X509_sign", referenced from:
crypto::gen_creds(std::__1::basic_string_view<char, std::__1::char_traits<char>> const&, unsigned int) in crypto.cpp.o
"_X509_verify_cert", referenced from:
crypto::cert_chain_t::verify(x509_st*) in crypto.cpp.o
"_X509_verify_cert_error_string", referenced from:
crypto::cert_chain_t::verify(x509_st*) in crypto.cpp.o
crypto::cert_chain_t::verify(x509_st*) in crypto.cpp.o
ld: symbol(s) not found for architecture arm64
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
Your brew environment is setup for the wrong architecture
How to verify my brew environment? And what should be the expected value?
I'm not sure, but it can't find the symbols for arm64
It seems my cmake command is different from the other Mac users':
==> Installing sunshine from lizardbyte/homebrew
==> Building docs: disabled
==> Disabled statically linking Boost libraries
==> cmake -S . -B build -DBUILD_WERROR=ON -DHOMEBREW_ALLOW_FETCHCONTENT=ON -DOPENSSL_ROOT_DIR=/opt/homebrew/opt/openssl@3 -DSUNSHINE_ASSETS_DIR=sunshine/assets -DSUNSHINE_BUILD_HOMEBREW=ON -DSUNSHINE_ENABLE_TRAY=O
==> make
While mine is
==> Installing lizardbyte/homebrew/sunshine-beta
==> Building docs: disabled
==> Disabled statically linking Boost libraries
==> make INSTALLPREFIX=/opt/homebrew/Cellar/sunshine-beta/2025.617.220707/miniup
==> cmake -S . -B build -G Unix Makefiles -DBUILD_WERROR=ON -DCMAKE_CXX_STANDARD
==> make -C build
What could be the possible cause of this?
Ok i have a fix, it looks like sunshine is trying to build against /usr/local/ and if you have used rosetta homebrew for x86 will install libs there, the fix is to temporarily move the deps to backup file and link to /opt/homebrew
mv /usr/local/opt/openssl@3 /usr/local/opt/[email protected]
mv /usr/local/opt/openssl /usr/local/opt/openssl.bak
ln -s /opt/homebrew/opt/openssl@3 /usr/local/opt/openssl
ln -s /opt/homebrew/opt/openssl@3 /usr/local/opt/openssl@3
brew install sunshine-beta
rm -rf /opt/homebrew/opt/openssl@3 /usr/local/opt/openssl /opt/homebrew/opt/openssl@3 /usr/local/opt/openssl@3
mv /usr/local/opt/[email protected] /usr/local/opt/openssl@3
mv /usr/local/opt/openssl.bak /usr/local/opt/openssl
@parzivale I tried to fix that problem in https://github.com/LizardByte/Sunshine/pull/2707 but it was unsuccessful.
Im not sure if the fix would have worked as it is not about sunshine not being able to find openssl but instead that it was prefering /usr/local over /opt/homebrew which meant it ended up linking against x86 libs instead of the arm ones, tho I'm not an expert in cmake or any of this
It seems this issue hasn't had any activity in the past 90 days. If it's still something you'd like addressed, please let us know by leaving a comment. Otherwise, to help keep our backlog tidy, we'll be closing this issue in 10 days. Thanks!
This issue was closed because it has been stalled for 10 days with no activity.