Xcode/Mac: RTAS still broken with latest tip

Audio Plugins
1

Hi,

We've tried several projects and it seems RTAS is still broken.

I get:

Undefined symbols for architecture i386:
  "CPlugInView::FindEnclosingView(CarbonDummyPointName)", referenced from:
      vtable for JucePlugInProcess::JuceCustomUIView in juce_RTAS_Wrapper.o
  "CProcessType::SetViewOrigin(long, CarbonDummyPointName)", referenced from:
      vtable for CEffectType in juce_RTAS_DigiCode1.o
      vtable for CEffectTypeRTAS in juce_RTAS_DigiCode1.o
      construction vtable for CDSPProcessType-in-CEffectType in juce_RTAS_DigiCode1.o
      construction vtable for CEffectType-in-CEffectTypeRTAS in juce_RTAS_DigiCode1.o
      construction vtable for CDSPProcessType-in-CEffectTypeRTAS in juce_RTAS_DigiCode1.o
  "CProcessGroup::SetViewOrigin(unsigned long, long, CarbonDummyPointName)", referenced from:
      vtable for CEffectGroup in juce_RTAS_DigiCode1.o
      vtable for CEffectGroupMIDI in juce_RTAS_DigiCode1.o
      vtable for JucePlugInGroup in juce_RTAS_Wrapper.o
      construction vtable for CEffectGroupMIDI-in-JucePlugInGroup in juce_RTAS_Wrapper.o
  "CProcessType::ChooseControl(long, CarbonDummyPointName, long*)", referenced from:
      vtable for CEffectType in juce_RTAS_DigiCode1.o
      vtable for CEffectTypeRTAS in juce_RTAS_DigiCode1.o
      construction vtable for CDSPProcessType-in-CEffectType in juce_RTAS_DigiCode1.o
      construction vtable for CEffectType-in-CEffectTypeRTAS in juce_RTAS_DigiCode1.o
      construction vtable for CDSPProcessType-in-CEffectTypeRTAS in juce_RTAS_DigiCode1.o
  "CProcess::SetViewOrigin(CarbonDummyPointName)", referenced from:
      vtable for CEffectProcess in juce_RTAS_DigiCode1.o
      construction vtable for CDSPProcess-in-CEffectProcess in juce_RTAS_DigiCode1.o
      vtable for CEffectProcessRTAS in juce_RTAS_DigiCode1.o
      construction vtable for CEffectProcess-in-CEffectProcessRTAS in juce_RTAS_DigiCode1.o
      construction vtable for CDSPProcess-in-CEffectProcessRTAS in juce_RTAS_DigiCode1.o
      vtable for CEffectProcessMIDI in juce_RTAS_DigiCode2.o
      construction vtable for CEffectProcess-in-CEffectProcessMIDI in juce_RTAS_DigiCode2.o
      ...
  "CProcess::ChooseControl(CarbonDummyPointName, long*)", referenced from:
      vtable for CEffectProcess in juce_RTAS_DigiCode1.o
      construction vtable for CDSPProcess-in-CEffectProcess in juce_RTAS_DigiCode1.o
      vtable for CEffectProcessRTAS in juce_RTAS_DigiCode1.o
      construction vtable for CEffectProcess-in-CEffectProcessRTAS in juce_RTAS_DigiCode1.o
      construction vtable for CDSPProcess-in-CEffectProcessRTAS in juce_RTAS_DigiCode1.o
      vtable for CEffectProcessMIDI in juce_RTAS_DigiCode2.o
      construction vtable for CEffectProcess-in-CEffectProcessMIDI in juce_RTAS_DigiCode2.o
      ...
  "CProcessGroup::ChooseControl(unsigned long, long, CarbonDummyPointName, long*)", referenced from:
      vtable for CEffectGroup in juce_RTAS_DigiCode1.o
      vtable for CEffectGroupMIDI in juce_RTAS_DigiCode1.o
      vtable for JucePlugInGroup in juce_RTAS_Wrapper.o
      construction vtable for CEffectGroupMIDI-in-JucePlugInGroup in juce_RTAS_Wrapper.o
ld: symbol(s) not found for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)

If I revert the changes from here:

https://github.com/julianstorer/JUCE/commit/82cc6b7183acabca16fdda557c12f507fc9f2efc

I get the Point errors.

 

I had RTAS builds working for at least a month ago.

 

2

Hi there! You're on a Mac, right?

I'm sorry but unfortunately I can't even compile the RTAS SDK on my Mac because apparently this requires the OSX 10.7 SDK or older... so I literally physically can't get into a state where I could debug that error :-(

If you have an old compiled version of it on your Mac (with older compiler/SDK), and then try to link your project against that RTAS library using some newer compiler/SDK, then yes I'd expect linker errors.

Just out of curiosity: does anyone still use RTAS these days? Wasn't that deprecated years ago in favour of AAX?

 

3

Hi Timur,

You're right RTAS is a bitch ;) and I've spent some time few months ago being able to compile it (for allowing 10.7 / libc++ to benefit new JUCE features with it).

Here is the thread:

http://www.juce.com/forum/topic/including-std-functions-aax/rtas-xcode

Summary, I've downloaded 10.6 SDK  (https://github.com/phracker/MacOSX-SDKs/releases) and built with it (symlink it to your Xcode app folder SDKs)

and compiled against it. remember it needs to be compiled for your libc++ if you're targeting 10.7+ (it will with some warning but it does work as expected under PT10.9 from my testings).

There are some some uncommenting to be done on the RTAS Library (like removing Components.h).

However with this build library I've been able to sucessfully build about a month ago. I'll try against JUCE commits to mention the exact one it was broken but it seems to be related to changes that also broke the VST3 for few commits. (Point.h / nasty PPC leftovers).

 

REASON FOR RTAS:
We're in a business where people believe computers shouldn't be connected to the network, never be upgraded, etc...
The company I currently work at tries to keep backward support as much as possible like many other software developers in this business. Some users are still running Pro Tools 9 or 8 and even 10.6 which is still a daily debate here wheter we should support it as long as possible or drop it for 10.7 and benefit the cool C++11 features (which we're already using in some upcoming products).

 

 

4

+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)

5

Here's a fix to make RTAS working again:

https://github.com/soundradix/JUCE/commit/17dd4e504694beee39c7cb78c94c1607a888f8b7

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

6

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...

7

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.

8

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!

9

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?

10

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.

11

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 
#endif

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).

12

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:

#!/bin/sh

SDKVER=$1
XCODEDIR="/Applications/Xcode.app"
SDKSRDIR="External/MacOSX_SDK"
SDKDSTPATH="$SDKSRDIR/MacOSX$SDKVER.sdk"
SDKDIR="$XCODEDIR"
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!"
else
echo "Info: Mac OS X SDK $SDKVER not found!"
cd $SDKSRDIR
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 ../..
else
echo "Error: Couldn't download SDK. Make sure you're connected..."
exit
fi
fi
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"
else
echo "Info: Good! seems like $SDKVER SDK already linked to Xcode install..."

fi


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

 

 

 

13

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.

14

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 ;) )

15

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.

16

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.

17

Latest fixes in main JUCE work fine for me.

Cheers, Yair

18

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...

Thanks

Timur

19

Hi Timur,

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

ASConnUtil.h:

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

And:

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

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)

 

Notes:

- 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 ;)

 

 

20

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 :-)