AU on XCode 10: ResMerger Error

For an error similar to this

For an error like this one, I found out that I had to have the following paths in my project “Rez Search Paths” (REZ_SEARCH_PATHS) build setting:



Rez build/\ -\ /Users/jenkins/Home/workspace/Pitchmonster\ OSX\ New/JuceLibraryCode/include_juce_audio_plugin_client_AU.r
    cd "/Users/jenkins/Home/workspace/Pitchmonster OSX New/Builds/MacOSX"
    /Applications/ -o /Users/jenkins/Home/workspace/Pitchmonster\ OSX\ New/Builds/MacOSX/build/\ -\ -d SystemSevenOrLater=1 -useDF -script Roman -d ppc_$ppc -d i386_$i386 -d ppc64_$ppc64 -d x86_64_YES -I /System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Versions/A/Headers -I /Applications/ -arch x86_64 -i /Users/jenkins/Home/workspace/Pitchmonster\ OSX\ New/Builds/MacOSX/build/Release -i /Users/jenkins/Home/workspace/Pitchmonster\ OSX\ New/Builds/MacOSX/../../Source -i /Users/jenkins/Home/workspace/Pitchmonster\ OSX\ New/Builds/MacOSX/../../JuceLibraryCode -i /Users/jenkins/Home/workspace/Pitchmonster\ OSX\ New/Builds/MacOSX/../../Source/CPU_Features -i /Users/jenkins/Home/workspace/Pitchmonster\ OSX\ New/Builds/MacOSX/build/Release -i /Users/jenkins/Home/workspace/Pitchmonster\ OSX\ New/Builds/MacOSX/build/Release/include -i ../../vst3 -i ../../JuceLibraryCode -i ../../aaxsdk -i ../../aaxsdk/Interfaces -i ../../aaxsdk/Interfaces/ACF -i ../../../Pitchmonster\ OSX\ New -i ../../juce/modules -i ../.. -i ../../juce/modules -i ../../juce/modules/juce_audio_plugin_client -i /Users/jenkins/Home/workspace/Pitchmonster\ OSX\ New/Builds/MacOSX/build/Release/include -i ../../vst3 -i ../../JuceLibraryCode -i ../../aaxsdk -i ../../aaxsdk/Interfaces -i ../../aaxsdk/Interfaces/ACF -i ../../../Pitchmonster\ OSX\ New -i ../../juce/modules -i ../.. -i ../../juce/modules -i ../../juce/modules/juce_audio_plugin_client -isysroot /Applications/ /Users/jenkins/Home/workspace/Pitchmonster\ OSX\ New/JuceLibraryCode/include_juce_audio_plugin_client_AU.r
failed to find AUComponent/AUComponent.r
/Applications/ ### Rez - noErr (0) during open of "AUComponent.r".
Fatal Error!
/Applications/ ### Rez - Fatal Error, can't recover.
AUComponent.r: ### Rez - Since errors occurred, /Users/jenkins/Home/workspace/Pitchmonster OSX New/Builds/MacOSX/build/ -'s resource fork was not completely updated.
Command /Applications/ failed with exit code 3

This is a patched version of JUCE 5.3.2 (you can enable legacy build using a commandline option on xcodebuild). With I think latest version of Xcode 10.

Jims-Mac-mini:/ jim$ find / 2>/dev/null | grep AUComponent.r 2>/dev/null

These are the locations that I have the missing AUComponent.r file on my new build mac which has the rez error.

And, on my normal Xcode 9 builds work fine Mac I have it in these locations:


So I don’t think that looks too surprising. Base SDK is set to default, so i assume both systems should be finding it in the folder /Applications/

Rez maybe has the wrong search path?

I’ll see if I can get it to give up its secrets.

Ok so ‘noErr’ looks weird. I’m going to run Rez inside dtruss when I get to the office, as I can’t dind a way to disable SIP so I can actually use dtruss remotely and find out why Rez feels the need to die … arrrrgh :slight_smile: .


bash-3.2# grep Err log
csrctl(0x0, 0x7FFEE690545C, 0x4)		 = -1 Err#1
access("/AppleInternal/XBS/.isChrooted\0", 0x0, 0x0)		 = -1 Err#2
stat64("/AppleInternal\0", 0x7FFEE6903660, 0x0)		 = -1 Err#2
gettid(0x7FFEE6902228, 0x7FFEE690222C, 0x0)		 = -1 Err#3
open_nocancel("/etc/.mdns_debug\0", 0x0, 0x0)		 = -1 Err#2
openat(0xFFFFFFFFFFFFFFFE, "/Library/Preferences/Logging/\0", 0x1000104, 0xFFFFFFFFE6901B08)		 = -1 Err#2
openat(0xFFFFFFFFFFFFFFFE, "/Library/Preferences/Logging/\0", 0x1000104, 0xFFFFFFFFE6903F48)		 = -1 Err#2
access("/System/Library/taggedstringsoff\0", 0x4, 0x0)		 = -1 Err#2
workq_kernreturn(0x4, 0x0, 0x0)		 = 0 Err#-2
workq_kernreturn(0x40, 0x70000DA38B80, 0x0)		 = 0 Err#-2
workq_kernreturn(0x100, 0x70000DA38B80, 0x1)		 = 0 Err#-2
workq_kernreturn(0x4, 0x0, 0x0)		 = 0 Err#-2
stat64("/usr/share/icu/icudt62l/keyTypeData.res\0", 0x7FFEE6904448, 0x0)		 = -1 Err#2
stat64("/usr/share/icu/icudt62l/supplementalData.res\0", 0x7FFEE69052D8, 0x0)		 = -1 Err#2
stat64("/usr/share/icu/icudt62l/likelySubtags.res\0", 0x7FFEE69024D8, 0x0)		 = -1 Err#2
stat64("/usr/share/icu/icudt62l/en_GB.res\0", 0x7FFEE6902A08, 0x0)		 = -1 Err#2
stat64("/usr/share/icu/icudt62l/pool.res\0", 0x7FFEE69028D8, 0x0)		 = -1 Err#2
stat64("/usr/share/icu/icudt62l/en_001.res\0", 0x7FFEE6902A28, 0x0)		 = -1 Err#2
stat64("/usr/share/icu/icudt62l/en.res\0", 0x7FFEE6902A28, 0x0)		 = -1 Err#2
stat64("/usr/share/icu/icudt62l/root.res\0", 0x7FFEE6902A38, 0x0)		 = -1 Err#2
stat64("/usr/share/icu/icudt62l/numberingSystems.res\0", 0x7FFEE6902A98, 0x0)		 = -1 Err#2
stat64("/usr/share/icu/icudt62l/curr/supplementalData.res\0", 0x7FFEE6902B38, 0x0)		 = -1 Err#2
stat64("/usr/share/icu/icudt62l/curr/pool.res\0", 0x7FFEE6902A08, 0x0)		 = -1 Err#2
stat64("/usr/share/icu/icudt62l/curr/en_GB.res\0", 0x7FFEE6902A38, 0x0)		 = -1 Err#2
stat64("/usr/share/icu/icudt62l/curr/en_001.res\0", 0x7FFEE6902A58, 0x0)		 = -1 Err#2
stat64("/usr/share/icu/icudt62l/curr/en.res\0", 0x7FFEE6902A58, 0x0)		 = -1 Err#2
stat64("/usr/share/icu/icudt62l/curr/root.res\0", 0x7FFEE6902A68, 0x0)		 = -1 Err#2
stat64("/usr/share/icu/icudt62l/en_US_POSIX.res\0", 0x7FFEE6902E68, 0x0)		 = -1 Err#2
stat64("/usr/share/icu/icudt62l/en_US.res\0", 0x7FFEE6902E88, 0x0)		 = -1 Err#2
stat64("/usr/share/icu/icudt62l/zone/en_GB.res\0", 0x7FFEE6904478, 0x0)		 = -1 Err#2
stat64("/usr/share/icu/icudt62l/zone/pool.res\0", 0x7FFEE6904348, 0x0)		 = -1 Err#2
stat64("/usr/share/icu/icudt62l/zone/en_001.res\0", 0x7FFEE6904498, 0x0)		 = -1 Err#2
stat64("/usr/share/icu/icudt62l/zone/en.res\0", 0x7FFEE6904498, 0x0)		 = -1 Err#2
stat64("/usr/share/icu/icudt62l/zone/root.res\0", 0x7FFEE69044A8, 0x0)		 = -1 Err#2
stat64("/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Versions/A/Headers\0", 0x7FFEE6905908, 0x0)		 = -1 Err#2
stat64("/Applications/\0", 0x7FFEE6905908, 0x0)		 = -1 Err#2
stat64("/Users/jenkins/Home/workspace/Pitchmonster OSX New/Builds/MacOSX/build/Release/include\0", 0x7FFEE6905908, 0x0)		 = -1 Err#2
stat64("/Users/jenkins/Home/workspace/Pitchmonster OSX New/Builds/MacOSX/build/Release/include\0", 0x7FFEE6905908, 0x0)		 = -1 Err#2
open("/Users/jenkins/Home/workspace/Pitchmonster OSX New/Builds/MacOSX/build/ -\0", 0xA00, 0x1B6)		 = -1 Err#17
__semwait_signal(0x1303, 0x0, 0x1)		 = -1 Err#60
__semwait_signal(0x1303, 0x0, 0x1)		 = -1 Err#60
workq_kernreturn(0x40, 0x70000D9B5B80, 0x1)		 = 0 Err#-2
workq_kernreturn(0x100, 0x70000DA38B80, 0x1)		 = 0 Err#-2

Shows complete list of errors for Rez.

Thanks - that fixed the issue. Cheers.

Still trying to find a fix here on our build machines.
It seems like the Rez - noErr (0) during open of “AUComponent.r”. is fixed by adding the required include paths manually.
We never had this issue. We’re still stuck with ResMerger - ERROR: errFSBadFSRef as posted in the first message here in this thread. Did anyone have this exact same error and managed to fix it?

I updated to XCode 11 and now I was getting the noErr(0) during open of "AUComponent.r error as well. An update to the latest commit on develop @ JUCE 5.4.5 has fixed this and I’m back at the ResMerger - ERROR: errFSBadFSRef. Apparently this indicates a corrupted drive / file system but we’re getting this error on multiple machines and it also appears when building from Thumb drives or external harddisks.

The ResMerge step that fails had just a single input file so I tried to copy that file to the output file path. This fixes the error and on the next build, it will succeed. There are two ResMerge steps involved, and this is the workflow to get around them:

  1. Build and see the build fail on the first ResMerge step.
  2. Copy Intermediates.noindex/ - to Intermediates.noindex/ -
  3. Build again and see the first ResMerge step succceed but the second ResMerge step fail
  4. copy Intermediates.noindex/ - to /Users/myUser/Library/Audio/Plug-Ins/Components/myBinaryName.component/Contents/Resources/myBinaryName.rsrc
  5. Build again and now it succeeds. I can load and use the resulting *.component so it appears to me that I’ve not done something totally stupid.
  6. Change a file and compile again and now you’ll have to do both copy steps again.

I’m still wondering what the issue could be.

BTW: The manual copying doesn’t work for release builds. Only Debug. So it’s useless.

I just stumbled on
### Rez - noErr (0) during open of "AUComponent.r".
error while building an old project that still use Juce 5.3.0 with XCode 11.2.
In my case setting REZ_SEARCH_PATHS as suggested didn’t work.

At last I fixed it by editing
changing #include path
#include <AudioUnit/AudioUnit.r>
#include <AudioUnit.r>

I don’t know if latest Juce version still has similar issues with XCode 11.2, but I see juce_audio_plugin_client_AU.r still uses same #include path in juce 5.4.5 (so maybe this fix will work as well).

Hope it helps, ciao!


The manual copy works for me in Release builds. Moreover, once you’ve gone through these steps, you can keep building as long as you don’t clean the project.
Saying that this is a pain in the ass is an understatement.

Interesting, what version of Xcode/OSX/DeploymentTarget are you working with?
It might give us more hints and help find the root of this problem.

I’m surprised that the JUCE staff doesn’t seem to care too much about this problem. It basically forces us to build on XCode 9.4.1 which doesn’t run on Catalina. This breaks all AU builds on Catalina and is a huge issue for us here. My forum account doesn’t show it but we are rocking multiple pro licenses and are a little surprised to see critical issues like this get ignored so much.

We certainly care about this problem, but we cannot reproduce it ourselves. As we said previously: any pointers on how to get things to break would be very valuable. Without being able to experiment it’s almost impossible to guess-debug a solution.

XCode 10.3 on OSX 10.14.6 exhibits the issue.
XCode 10.1 on the same platform doesn’t.
Deployment target is macOS 10.11

I’ve just done a clean build of AudioPluginDemo using Xcode 10.3 on 10.14.6 targeting 10.11.

Unfortunately, no problems here.

The machine does have both older and newer versions of Xcode installed side by side.

Perhaps the difference is in the selected version of Command Line Tools?

I’m struggling with this as well, but only for Release builds. Debug is fine.

Ok, I think it’s resolved for me. My build folder is usually /Volumes/Lolrus/dev.github/project and I access it from a symbolic link in my home directory. If I try and build in this folder it fails. I’ve moved my build folder to ~/dev and now it seems to build fine.

Just did a clean and rebuild to confirm everything is building. I could manually copy the .rsrc file and it would buld fine in Xcode, but not from xcodebuild.

So everything is working as expected following the copy to a path under your home directory?

That reminded me of something similar from a few years ago

Well, it solved my problem back then. To build anything with JUCE, including the examples or Projucer, I have to move them from my JUCE folder in the /Developer/ path to somewhere in my user path. If it’s anywhere near the JUCE folder in my /Developer/ path, Rez Error 3.

I’m having a similar issue using FRUT since I started using the OSX 10.15 SDK.

I can’t reproduce this issue with Projucer, so doesn’t seem to be exactly the same. But the latest SDK has some changes in AudioUnit.r that could be relevant.

Here are the full details incase this helps -

A quick update from us:
We noticed that all of a sudden, all errors disappeared on one machine (Catalina, Xcode 11.2.1). The only change we made was to set the AAX copy path to the user directory (so that we can build AAX without root permissions). This was done in the Projucer project file in one of our projects. It seems completely unrelated, but it is the only thing we changed. I tried to replicate this on another machine (Mojave, Xcode 11.2.1), but here the errFSBadFSRef error doesn’t vanish when changing the AAX copy path. Both times, I was running the build directly from the XCode GUI and from the command line with identical results.

Bottom line: Something on our first machine changed, and we don’t know what it is. This is really frustrating