[macOS] [Arm] Build: List of issues when building locally on an M1 Mac

[shinra-electric]

Quick summary

I haven't been able to build on macOS Sonoma and Xcode 15 since I upgraded. (I can't downgrade to Ventura as it's a work laptop).
But over Christmas I had access to an M1 with Ventura still installed and managed to work through some of the issues I was having. I was able to build a working app with Ventura and a broken app with Sonoma. I suspect the Sonoma app is broken due to the new Linker in Xcode 15. Fixed. See below for details

Note that the app built with Ventura will work fine on Sonoma.

I thought I'd list the issues and workarounds here so someone more knowledgeable than me might be able to fix some of them.

Details

• Old-style-cast errors: Fixed by Fix Apple Clang build #15240

• glslang: needs to be uninstalled from homebrew, or else the build will fail. This is documented in [macOS] [Arm] Building on Arm fails if glslang is installed locally via homebrew #13540 Fixed

• cubeb: needs to be uninstalled from homebrew, or else the build will fail.
  Log file:
  cubeb.txt

• llvm: CMake complains that llvm 17 or 18 are not acceptable, and that llvm@16 is required. However this warning can be ignored.

• libfreetype.6.dylib: incorrect loader_path. brew reinstall freetype should fix this. If not, another workaround is in the comments below.

• ffmpeg 7: There has been a change to a variable name in ffmpeg 7. (Workaround below) fixed.

It's possible to build with the following instructions:

# install dependencies
brew install cmake ffmpeg glew libusb llvm molten-vk nasm ninja pkg-config qt@6 sdl2 vulkan-headers
brew rm cubeb

export Qt6_DIR=$(brew --prefix)/opt/qt6
export VULKAN_SDK=$(brew --prefix)/opt/molten-vk
if [ ! -h "$VULKAN_SDK/lib/libvulkan.dylib" ]; then 
	ln -s "$VULKAN_SDK/lib/libMoltenVK.dylib" "$VULKAN_SDK/lib/libvulkan.dylib"
fi 
export VK_ICD_FILENAMES=$VULKAN_SDK/share/vulkan/icd.d/MoltenVK_icd.json
export LLVM_DIR=$(brew --prefix)/opt/llvm

git clone --recursive https://github.com/RPCS3/rpcs3
cd rpcs3

# Fix hidapi
sed -i '' "s/extern const double NSAppKitVersionNumber;/const double NSAppKitVersionNumber = 1343;/g" 3rdparty/hidapi/hidapi/Mac/hid.c

# Configure build system
cmake . -B build -DUSE_ALSA=OFF \
	-DUSE_PULSE=OFF \
	-DUSE_AUDIOUNIT=ON \
	-DUSE_NATIVE_INSTRUCTIONS=OFF \
	-DUSE_SYSTEM_FFMPEG=on \
	-DCMAKE_OSX_ARCHITECTURES="arm64" \
	-DLLVM_TARGETS_TO_BUILD="AArch64;ARM" \
	-GNinja \
	-DUSE_SYSTEM_MVK=on \
	-DUSE_SDL=ON \
	-DUSE_SYSTEM_SDL=ON \
	-DUSE_FAUDIO=OFF \
	-DBUILD_LLVM=OFF\
	-DUSE_SYSTEM_LIBPNG=ON \
	-Wno-deprecated

# Build
ninja -C build
codesign --force --deep --sign - build/bin/rpcs3.app/Contents/MacOS/rpcs3

Sonoma crash

The Sonoma build crashes on launch saying it cannot find the bundled libraries. However, they are correctly bundled within the app.
Crash report:
rpcs3 arm crash report sonoma.txt

This is fixed. The issue was with libfreetype.6.dylib. The @loader_path was incorrect. Referring back to the Ventura build with otool I could see it should be @executable_path, and it was pointing to the wrong place. But install_name_tool refused to change it, saying it would invalidate the signature. So I removed the signature and then changed it. This was successful.

Edit: Reinstalling with brew reinstall freetype seems to have fixed the underlying issue for me. The workaround may not be required.

System configuration

M1 Pro
Ventura 13.6.3 & Xcode 14.3.1
Sonoma 14.3 Beta & Xcode 15.1

Edit: Removed advice about using the interpreter. LLVM is now working.

[shinra-electric]

Just to show that the Ventura arm64 build runs on Sonoma, here is Kiryu looking badass as usual...

[shinra-electric]

I found a CMake post here about the Apple Clang 15 linker issue, and apparently it's recommended to use the old linker with LDFLAGS=-Wl,-ld_classic until Apple sort it out.

I tried adding -DLDFLAGS=-Wl,-ld_classic but I didn't notice any difference.

It was mentioned in that post that CMakeLists.txt might have to be modified, but I wouldn't know how to do this.

In general the CMake-using projects need to update their CMakeLists.txt to deal with whatever obsolete/incorrect flags are emitted by their options.

[PrideChung]

Sonoma crash
The Sonoma build crashes on launch saying it cannot find the bundled libraries. However, they are correctly bundled within the app.
Crash report:
rpcs3 arm crash report sonoma.txt

@shinra-electric Maybe it's caused by homebrew? Take a look at this issue, its exception message looks similar to yours: link

I haven't figured out how cmake copies dylibs into rpcs3.app, but using install_name_tool to correct the rpath of libfreetype.dylib should work.

[shinra-electric]

Using otool on libfreetype.6.dylib in the Sonoma build I get:

libfreetype.6.dylib:
	@executable_path/../Frameworks/libfreetype.6.dylib (compatibility version 27.0.0, current version 27.1.0)
	/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
	/usr/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.8)
	@loader_path/../../../../opt/libpng/lib/libpng16.16.dylib (compatibility version 57.0.0, current version 57.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.100.3)

Whereas if I use otool on the Ventura build I get:

libfreetype.6.dylib:
	@executable_path/../Frameworks/libfreetype.6.dylib (compatibility version 27.0.0, current version 27.1.0)
	/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
	/usr/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.8)
	@executable_path/../Frameworks/libpng16.16.dylib (compatibility version 57.0.0, current version 57.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.100.3)

So we can see the executable path is correct, but the path referencing libpng16.16.dylib is wrong. It should be @executable_path/../Frameworks/libpng16.16.dylib

[shinra-electric]

When trying to change the path with install_name_tool it fails and I get a warning that doing this would invalidate the signature:

➜  install_name_tool -change libpng16.16.dylib @loader_path/../Frameworks/libpng16.16.dylib libfreetype.6.dylib
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool: warning: changes being made to the file will invalidate the code signature in: libfreetype.6.dylib

I'm looking for a way to force the change, but I haven't found one yet....

[shinra-electric]

Ok, I've figured out how to fix the last issue when building on Sonoma.

The issue is only with libfreetype.6.dylib where the @loader_path is incorrect. Install_name_tool refused to change it because it would invalidate the signature. I couldn't find a way to force-change it, so I just removed the signature.

So the workaround is to change this line:
ninja && codesign --force --deep --sign - bin/rpcs3.app/Contents/MacOS/rpcs3
to this:

ninja
codesign --remove-signature bin/rpcs3.app/Contents/Frameworks/libfreetype.6.dylib 
install_name_tool -change @loader_path/../../../../opt/libpng/lib/libpng16.16.dylib @executable_path/../Frameworks/libpng16.16.dylib bin/rpcs3.app/Contents/Frameworks/libfreetype.6.dylib
codesign --force --deep --sign - bin/rpcs3.app/Contents/MacOS/rpcs3

[shinra-electric]

Actually, if anyone is getting the libfreetype.dylib crash on Sonoma, instead of doing the workaround can you try reinstalling freetype?

brew reinstall freetype may have fixed it for me

[meh7an]

I'm not sure if the workaround for the libfreetype.dylib is working for me.
I'm trying to do the workaround, but in second line I get this error:

codesign --remove-signature bin/rpcs3.app/Contents/Frameworks/libfreetype.6.dylib 
install_name_tool -change @loader_path/../../../../opt/libpng/lib/libpng16.16.dylib @executable_path/../Frameworks/libpng16.16.dylib bin/rpcs3.app/Contents/Frameworks/libfreetype.6.dylib

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool: fatal error: file not in an order that can be processed (link edit information does not fill the __LINKEDIT segment): bin/rpcs3.app/Contents/Frameworks/libfreetype.6.dylib

Although the next line gives me bin/rpcs3.app/Contents/MacOS/rpcs3: replacing existing signature and the app can be run, but opening anything, including any settings causes the whole app to crash. Not sure if these are related though.

System Configuration

M3 Max
Sonoma 14.2.1

[shinra-electric]

...the app can be run, but opening anything, including any settings causes the whole app to crash. Not sure if these are related though.

If the app can be run, then you built it successfully. But the crash you are having sounds like issue #14997. I never had that crash, so I haven't been able to look into it...

[zo26]

...the app can be run, but opening anything, including any settings causes the whole app to crash. Not sure if these are related though.

If the app can be run, then you built it successfully. But the crash you are having sounds like issue #14997. I never had that crash, so I haven't been able to look into it...

I couldn’t get the build to run following your instructions on Sonoma. Something about the code didn’t install the library into the contents folder when running ninja. However, an earlier version runs as-is from the RPCS3 website. Was able to run College Football Revamped with a steady frame rate on M1Max Studio. It did freeze, but I didn’t wait to see if it was only momentary. I believe it was 0.0.29-15623

[shinra-electric]

Something about the code didn’t install the library into the contents folder when running ninja.

Are you sure you had all the dependencies installed? Which library are you referring to? If you export the terminal output into a .txt file and post here I can have a look at it.

However, an earlier version runs as-is from the RPCS3 website. Was able to run College Football Revamped with a steady frame rate on M1Max Studio.

Do not expect the Arm build to run anything at all. Only a handful of games are know to work. If you want to play games, download the x64 build and run through Rosetta.

[zo26]

Something about the code didn’t install the library into the contents folder when running ninja.

Are you sure you had all the dependencies installed? Which library are you referring to? If you export the terminal output into a .txt file and post here I can have a look at it.

However, an earlier version runs as-is from the RPCS3 website. Was able to run College Football Revamped with a steady frame rate on M1Max Studio.

Do not expect the Arm build to run anything at all. Only a handful of games are know to work. If you want to play games, download the x64 build and run through Rosetta.

Here's the log
rpcs3 terminal log.txt

[shinra-electric]

Here's the log

From a quick glance it looks like you didn’t apply the fixes from PR #14452

[zo26]

I'm still stuck at the
ninja: build stopped: subcommand failed. bin/rpcs3.app/Contents/Frameworks/libfreetype.6.dylib: No such file or directory

result in terminal. For context, I never had an RPCS3 install prior to trying to install on Sonoma. Just wanted to mention since I saw references to applying Ventura fixes/workarounds to the Sonoma version.

[shinra-electric]

For anyone following this, it's no longer necessary to patch in the old-style-cast workaround into the code, it has been fixed in the master branch.

[shinra-electric]

I've added an issue with ffmpeg 7 to the original post, and added a workaround to the build instructions

[kd-11]

On latest master, we have native arm64 support added to LLVM on macos. You can now play games with full LLVM JIT to maximize performance.

[nevack]

On latest master, we have native arm64 support added to LLVM on macos. You can now play games with full LLVM JIT to maximize performance.

Will there be available prebuilt binaries for macOS-arm64?

[AniLeo]

#12599. We need someone to add CI.

[mavethee]

Well, there's this #14028 if someone is willing to resurrect it from the grave.

[AniLeo]

# Change variable name in ffmpeg 7
sed -i -e 's/frame_number/frame_num/' ./rpcs3/util/media_utils.cpp

Is this still valid? I can't find any occurrences of frame_number in media_utils.cpp

[kd-11]

Definitely not, when I build locally I don't do any weird customization. Just install the same deps we have for x64 and build. The one thing I do for better compatibility is to use llvm@18 instead of llvm@16 for the improved CPU detection.

[kd-11]

I didn't have to do anything with cubeb either, though I don't build x64 rpcs3 on macos these days so it is likely a conflict with the x64 build setup on affected systems.

[shinra-electric]

Is this still valid? I can't find any occurrences of frame_number in media_utils.cpp

Thanks for pointing this out. It's not needed anymore, I'll remove it from the original post

I didn't have to do anything with cubeb either, though I don't build x64 rpcs3 on macos these days so it is likely a conflict with the x64 build setup on affected systems.

The cubeb issue is only if you have homebrew cubeb installed at the same time. For some reason it interferes with the build, so my workaround was just to remove the local install and re-install afterwards (if it exists). I couldn't see any -DUSE_SYSTEM_CUBEB flag that I could turn off in CMakeLists.txt.

Here is a log:

Terminal Saved Output.txt

Edit: I don't have any x64 homebrew installations, so it's unlikely to be caused by CPU architecture issues.