Xcode/Mac: RTAS still broken with latest tip

+1, on the same boat as you for having to keep backwards compatibility with ancient systems.

(And I happen to have fought just yesterday a fierce battle to build RTAS on Windows with Visual Studio 2013.. I fear the tought of having to do the same on Mac when monday comes)

Here's a fix to make RTAS working again:


In the error above you can see it looks for symbols with parameters of CarbonDummyPointName, which is defined by JUCE and not in the actual RTAS lib.

Cheers, Yair

OK, but that just reverts Jules' commit, right?

I bet he had a good reason for that commit, presumably fixing RTAS compilation on some other platform...

It would be good to get Jules' feedback as it touches on his recent changes.

Iiuc, this commit https://github.com/julianstorer/JUCE/commit/4b4b8df491cb27c72f7466dd5923f27f5bca0516 broke the RTAS build, and then commit https://github.com/julianstorer/JUCE/commit/82cc6b7183acabca16fdda557c12f507fc9f2efc perhaps fixed compile errors but after it there were still link errors.

My fix reverts the second small commit and fixes the problems introduced by the first commit, thought not by reverting it.

OK, so if that's not urgent (i.e. you have something locally that lets you compile RTAS), I'd prefer to wait until Jules is back from NAMM and then get his opinion on this!

I'm also stuck here... well not really stuck but I'd prefer to have things running with the latest tip. Jules, could you maybe comment on this?

I am trying right now to get RTAS plugins to compile on my Macbook with the latest JUCE tip running OSX 10.11. (I don't have an older system here so can't check that). Let's see if I can make it work :-) I'll post something soon.

Also, after discussing the RTAS topic with Jules, we pretty much agree that we will try to keep it working if we can (within reasonable effort), so we don't break your legacy stuff, but no new development will go into the RTAS wrapper (= new features like multibus will not be implemented for RTAS) and we will deprecate it.

OK, everyone, I fixed RTAS compilation on the newest tip, which surprisingly even works with the current Xcode 7.2 and OSX 10.11 El Capitan.

Here's a few infos:

You have to compile everything (the RTAS library itself as well as your JUCE plugin) with the following settings:

Base SDK: Mac OS X 10.6
OS X Deployment Target: OS X 10.6
C++ Language Dialect: C++98 [-std=c++98]
C++ Standard Library: libstdc++ (GNU C++ standard library)

For this you obviously need the 10.6 SDK, which you can download here and then put into /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs.

Unfortunately I could not succeed with compiling RTAS with any SDK newer than 10.6 because I could not get past the 'RegEntryID' compiler error described at the end of this post (if anyone knows how to get past this, please enlighten me)

You will also encounter a compilation error inside the RTAS SDK itself at this piece of code:

#ifdef __GNUC__ && __POWERPC__ 
    #include <ppc_intrinsics.h> // needed for __eieio 

The DigiDesign guys seem to have trouble with using the syntax of #if and #ifdef correctly ;-) Anyway, the fix is to just remove this bit of code altogether as we are obviously not on a PowerPC (and please don't ask for PowerPC support...)

Another catch is that our current AudioUnit wrapper does not compile with such an ancient SDK as OS X 10.6. So basically this means that you can't have a jucer project with AU and RTAS enabled simultaneously, as depending on what SDK you choose one of the two will always fail to compile.

I'd suggest that you keep a legacy jucer project with the SDK set to 10.6 if you need to compile old stuff with RTAS, and use another one with the current SDK for all new development.

FYI, we will do our best to maintain this way to get RTAS compiling (so as not to break your legacy stuff), but we will deprecate RTAS and we won't put any new development into RTAS (so for example new features like multibus won't be ported to RTAS). I also won't attempt to fix our AU wrapper to compile with the ancient OSX 10.6 SDK. We strongly advise you to give up RTAS and move to AAX instead. Many major audio software companies like e.g. Native Instruments have already done this a while ago.

Edit 02/02/2016: it turns out you can compile your plugin using C++11 and the newest OSX SDK as long as the PT_SDK library itself is compiled with the 10.6 SDK (see the rest of the thread below).

Great that it's fixed though I'd suggest looking at Yair's patch as it doesn't require using 10.6 SDK for JUCE and I've been sucessfully building RTAS with 10.7/c++11 libcpp enjoying the modern features of latest JUCE with compromising.

And for SDK I'd suggest using symlink as you're not guarranted adding something to the Xcode.app folder will remain there with upgrade ;)

We're using this script for downloading:


if [[ ! -d "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX$SDKVER.sdk" ]] && [[ ! -L "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX$SDKVER.sdk" ]]; then
if [ -d "$SDKDSTPATH" ]; then
echo "Info: Mac OS X SDK $SDKVER found!"
echo "Info: Mac OS X SDK $SDKVER not found!"
echo "Downloading Mac OS X $SDKVER SDK..."
curl -L "https://github.com/phracker/MacOSX-SDKs/releases/download/MacOSX10.11.sdk/MacOSX$SDKVER.sdk.tar.xz" -o "MacOSX$SDKVER.sdk.tar.xz"
if [ -f "MacOSX$SDKVER.sdk.tar.xz" ]; then
echo "Unpacking Downloaded SDK..."
tar xf "MacOSX$SDKVER.sdk.tar.xz"
echo "Removing tarball..."
rm "MacOSX$SDKVER.sdk.tar.xz"
cd ../..
echo "Error: Couldn't download SDK. Make sure you're connected..."
echo "Trying to link $SDKVER SDK to your Xcode Install (might ask for su...)"
sudo -s ln -s "$(pwd)/$SDKDSTPATH" "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX$SDKVER.sdk"
echo "Info: Good! seems like $SDKVER SDK already linked to Xcode install..."


I understand not supporting RTAS / deprecating it but crippiling current possible functionality is less than desirable.




Sorry ttg, it wasn't my intent to "cripple" anything, I actually attempted to fix it!

I have nothing against compiling RTAS with the current SDK, I just couldn't get it to work, but I'll check out the patch you mentioned (I wasn't aware of it) and give it another try.

Hi Timur,

My apologizes!

Removing those DummyPointers look good here! I've been able to compile JuceDemoPlugin with 10.7 / libcpp against RTAS PluginLib build with those settings. I've also looked at the commit and it looks fine.

You don't need to use the 10.6 SDK for building as I've used the latest (I'm with 10.11 Xcode 7.2) and it builds fine. I'll put the built plug-in on my PT10 / 10.9 test rig tomrrow.

Please forgive me writing before testing...

I'm back to the point as here: http://www.juce.com/comment/317287#comment-317287

Which is good enough for a year or two until we can ditch this ugly RTAS format.

If it still fails for you building with the RTAS library let me know so I can private message you the exact diffs we did. I remember about 2-3 moddings required for VS2015 and Xcode 7.2 (with 10.6SDK) building properly...

(as long as you don't mind the tons of warnings ;) )

Interesting that it works for you. I also used the juce demo plugin and RTAS did *not* compile with OSX SDK 10.7 or newer.

May I ask what version of the RTAS SDK you (or RTAS folk in general) are normally using? Mine is "PT_80_SDK", I suspect that this might be the reason.

Yep. there's PT_90_SDK which is the latest and we work with it.

Feel free to pm me though you're more skillful than me and already had the hard time with Avid's libs ;)

PT90 works for me now with Deployment 10.6 and libstd and Deployment 10.7 and libcpp.

The project of course should be the same as the library in terms of libcpp/libstd.

I've made our configurations comply with Avid's AAX configurations and with suggested commit (http://www.juce.com/forum/topic/aax-libc-library) this works pretty elegant.


* p.s. - keep in mind I compile the libcpp against 10.6SDK but with Deployment 10.7. this gives warnings but at least it builds and works.

Latest fixes in main JUCE work fine for me.

Cheers, Yair

Hi Yair, ttg, and anoyone for whom the latest tip is working,

OK I got the PT_90_SDK now, using Xcode 7.2, OSX 10.11 SDK, and Deployment target 10.7. I still can't get it to compile. Here are my steps after I changed from PT_80_SDK to PT_90_SDK:

First it failed because the compiler was set to gcc, I set it to clang. Then I set c++11 and libc++, OSX SDK 10.11 and Deployment Target 10.7.

Then I hit the <ppc_intrinsics.h> again, fixed that.

Then I hit a very funny preprocessor error: "#error Help Old MacDonald find his farm on this platform!" I fixed that by setting the build architecture to 32-bit only.

However now I am stuck with these compiler errors:

/Users/timur/SDKs/PT_90_PlugInSDK/AlturaPorts/TDMPlugIns/PlugInLibrary/DSPClasses/CDSP.cpp:1092:10: No matching function for call to 'Call_DsiGetHostBit'
/Users/timur/SDKs/PT_90_PlugInSDK/AlturaPorts/TDMPlugIns/PlugInLibrary/DSPClasses/CDSP.cpp:1148:10: No matching function for call to 'Call_DsiGetHostBit'
/Users/timur/SDKs/PT_90_PlugInSDK/AlturaPorts/TDMPlugIns/PlugInLibrary/DSPClasses/CDSP.cpp:1268:10: No matching function for call to 'Call_DsiGetHostBit'

I think when I hit that with PT_80_SDK I solved it by using the OSX 10.6 SDK but the point is that people want to be able to use a newer SDK, right? Do you know how to get past this? Any help would be greatly appreciated...



Hi Timur,

I hope this will be sufficient and helpful. from a scratch PT90 here is the modifications:


#if !(__i386__)
    #ifdef __GNUC__ && __POWERPC__
        #include <ppc_intrinsics.h> // needed for __eieio


// MacOS headers 
    #include "Mac2Win.H"
    #include <Components.h>

In addition, check your compileflags file. I have to admit I've made sure all DSP code is set to 0 so I guess it might won't support TDM plug-ins (which are old Motorola DSP chips based aren't supported by JUCE anyway)



- You still need to build against SDK 10.6! (only the library! your juce project will work with latest SDK and WILL link to the library just fine)

- You should create additional configuration in Xcode with Deployment Target 10.7 and libcpp to link against C++11 projects. (eg. if you want to use OSC or AudioProcessorParameterValueTree...)


Let me know if you've been sucessful. technically you should be able to build Equator as RTAS ;)



Hey ttg,

thanks! This works now. The thing I didn't get is that you have to compile the RTAS SDK with 10.6 SDK and libstdc++, but then still can compile and link the plugin with 10.11 SDK and libc++!

No further modifications to JUCE are needed when the RTAS SDK is compiled in the way you've described. Looks like we're finally done here :-)

Has anyone had any luck getting RTAS’ PluginLibrary to build with Xcode 7.3? When I install the SDK into /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk, Xcode still won’t recognise it - even after a restart. I can’t select it in the Base SDK Build Settings menu and if I specify it manually it says “SDK not found”. Any hints?

I havent confirmed this workaround myself but there’s a guide here http://stackoverflow.com/questions/36293355/mac-os-x-10-6-sdk-no-longer-works-with-xcode-7-3

1 Like

Yup that worked! Thank you!