PT8 + AU universal binary + xcode 4.3 + base sdk 10.5?


#1

Hey guys,

I’m trying to get xcode 4.3 to play with me, but it’s not being a good friend. First of all we don’t want PPC so that makes things a bit easier (but not a lot). Our plugin is configured using Introducer, for 3 formats: vst, au and protools. For protools we use the PT8.0 SDK. No AAX yet, that doesn’t seem to be quite ready for production yet :slight_smile:

[list]
[] it seems impossible to build the PT8.0 “PluginLib” in 64-bit + 32 bit universal binary. I can build it in 32 bit. This means effectively that I can’t afterwards I won’t be able to build our plugin in 32/64bit universal… Has anyone had any luck building
PluginLib on mac for 64 bits? If this fails, is there any way to tell the introjucer to build the PT plugin in 32-bit only and the rest of the plugin in 32+64 universal?[/
]
[] I installed the last Apple Core Audio SDK that is compatible with Lion. This seems to work OK (after a small bug fix in their sources), but is incompatible with anything below base sdk 10.7. Apple being apple it is impossible to download a Core Audio SDK for 10.5. Does anyone have a version of xcode with a core audio sdk compatible with 10.5? If so, could you possibly zip it up for me and send it to me? I’m downloading an xcode 3.1.4 dmg which will hopefully contain the same, but extracting it might be hard![/][/list]

Any extra hints on building things with xcode 3.4 but retaining compatibility with older base SDKs and UB binaries would be really appreciated…

greetings,

  • bram

#2

Hi bram,

Are you attempting to build a 64-bit RTAS? If so, I’m not surprised you’re having difficulties. All versions of Pro Tools with RTAS support are 32-bit programs - they wouldn’t load a 64-bit plugin even if you succeeded in building one. If you’re trying to build a “polymorphic” plugin then you probably need to just switch off the RTAS code for the 64-bit build. I could be wrong, but I don’t think Juce does it automatically. Perhaps it should.

We’re also using Xcode 4.3, but with PT90_SDK and separate configs (and build products) for RTAS, AU & VST. The latter two are fat binaries. I had to hack the VST wrapper to exclude updateComponentPos() and viewBoundsChangedEvent() in the 64-bit pass to get it working, but I think that’s been fixed in the latest version of Juce.

Even with the 10.7 SDK you should be able to make binaries that are compatible with previous versions of OSuX by setting Deployment Target to 10.5, as long as you haven’t used any new features.

Rupert


#3

Hello Rupert,

I’m not trying to build 64-bit PT versions, I was just wondering how my build just worked: PluginLib is built as 32bit, my actual polymorphic plugin is UB. In my head this is black magic. How could the linking stage work for UB if for building you only have one bit-depth to link against.

You say you have different configs/build-products, but I suppose this means you have multiple .jucer files?

I know I can set the deployment target to 10.5 with the 10.7 SDK, but this does not guarantee functioning code in 10.7. Especially (I would imagine) when also combining this with newer versions of the AU SDK. I mean, if I use an AU SDK from 2012 and try to load it in a program built in 2008 what are the chances of this working. How is the backwards-compatibility of AU?

It’s a bit of a mess :slight_smile:

  • bram

#4

By the way, last but not least, with llvm clang I get build errors in Juce and the VST GUI. With GCC all works fine. That seems another tricky part…

  • bram

#5

I’m no expert, but my understanding of building universal binaries is that it’s equivalent to* doing two builds for 32- and 64-bit then joining the binaries at the end. Apple’s compilers provide a command line option -Xarch for adding options exclusively to one architecture. I’ve never used it myself, but you should be able to link against PluginLib only for the 32-bit pass, then use preprocessor macros to exclude the code that depends on it in the 64-bit pass.

  • probably not how it works

I don’t actually maintain the projects using the Introjucer directly. I have a single dummy project that I occasionally modify, then import the changes into the real project(s). I find I often need to make manual changes to Introjucer projects after saving them because of features that Introjucer (or at least the version I’m using) doesn’t have, like multiple configurations or separate linker flags for debug and release.

I’d be surprised if it didn’t unless you were using some deprecated API functions that were taken out in the later version (but then you’d run into build errors?). The deployment target is supposed to be the minimum supported OS. This is enforced by the OS for applications, but plugins sometimes work even on an earlier version. You can use API features from a more recent version up until the base SDK if you check for support at runtime before calling into the new APIs, but this probably isn’t relevant to Juce users. This guy explains it quite well http://www.clarkcox.com/blog/2009/06/23/sdks-and-deployment-targets/

Quite high as long as you don’t use API features introduced since 2008, or you put checks in the Obj-C code to find out what’s supported. What would be the point in a public API if the existing interface doesn’t stay reasonably consistent? :slight_smile:


#6

OK, this all makes a lot of sense thanks a lot for the patience/explaining!!
FYI: the introjucer now DOES have quite a few more features than before and seems to have become a lot smarter (I think Jules is doing the xarch thing somehow).
I guess in the end it’s simply a fact that we’ll need to test :wink:

  • bram