[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 is not acceptable, and that llvm@16 is required. However this warning can be ignored.

• libfreetype.6.dylib: incorrect loader_path. Workaround below. (Edit: brew reinstall freetype may also work).

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

It's possible to build with the following instructions:

# install dependencies
brew install cmake ffmpeg glew libusb llvm@17 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
ln -s "$VULKAN_SDK/lib/libMoltenVK.dylib" "$VULKAN_SDK/lib/libvulkan.dylib"
export VK_ICD_FILENAMES=$VULKAN_SDK/share/vulkan/icd.d/MoltenVK_icd.json
export LLVM_DIR=$(brew --prefix)/opt/llvm

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

# Update only the submodules that are needed
git submodule update --init ./3rdparty/asmjit
git submodule update --init ./3rdparty/cubeb
git submodule update --init ./3rdparty/curl
git submodule update --init ./3rdparty/flatbuffers
git submodule update --init ./3rdparty/glslang
git submodule update --init ./3rdparty/hidapi
git submodule update --init ./3rdparty/libusb
git submodule update --init ./3rdparty/miniupnp
git submodule update --init ./3rdparty/pugixml
git submodule update --init ./3rdparty/rtmidi
git submodule update --init ./3rdparty/SoundTouch
git submodule update --init ./3rdparty/SPIRV
git submodule update --init ./3rdparty/wolfssl
git submodule update --init ./3rdparty/xxHash
git submodule update --init ./3rdparty/yaml-cpp

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

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

# Configure build system
mkdir build && cd build
cmake .. -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_FAUDIO=OFF \
	-DBUILD_LLVM=OFF\
	-DUSE_SYSTEM_LIBPNG=ON \
	-Wno-deprecated

# Build
ninja && codesign --force --deep --sign - 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

Note

In order to run games with an arm64 build, use the PPU Static Interpreter and the SPU Dynamic interpreter.
Only a short list of games have been confirmed to run on arm, including:

• The Arkedo series
• Dragon's Crown
• Odin Sphere
• Ryu Ga Gotoku 1 & 2 HD Remaster (Japan only)
• Ratchet & Clank 1-2-3 HD Remasters (broken cutscenes)

[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