AU built using 10.6 base sdk - not loaded in 10.5

Audio Plugins
1

Hi,
I’m new to mac os programming, so I need your help badly

I’ve built an AU plugin using base sdk 10.6 (mac os x 10.6.2, intel mac, xcode 3.2.1)
deployment target is set to 10.4
Plugin opens ok in AUlab in 10.6.2
But in 10.5 I getting error “50” while trying to load plugin to aulab.

auval -v aufx gives the following -

     AU Validation Tool
     Version: 1.2.1b3 
      Copyright 2003-2007, Apple, Inc. All Rights Reserved.

     Specify -h (-help) for command options

VALIDATING AUDIO UNIT: ‘aufx’ - ‘Tr’ - ‘SlDl’

Manufacturer String: SlDl
AudioUnit name: Tr
Component Info: Tr
Component Version: 1.1.0 (0x10100)
Component’s Bundle Version: 0.0.0

    • PASS

TESTING OPEN TIMES:
COLD:
2010-01-30 22:56:05.789 auvaltool[142:80f] Error loading /Library/Audio/Plug-Ins/Components/Tr.component/Contents/MacOS/Tr: dlopen(/Library/Audio/Plug-Ins/Components/Tr.component/Contents/MacOS/Tr, 262): Symbol not found: _ZNSi10_M_extractIfEERSiRT
Referenced from: /Library/Audio/Plug-Ins/Components/Tr.component/Contents/MacOS/Tr
Expected in: /usr/lib/libstdc++.6.dylib
FATAL ERROR: OpenAComponent: result: -50,0xFFFFFFCE

I’ve tried to build using base sdk 10.5 and plugin loads ok in 10.5 and 10.4, but I need to use base sdk 10.6

Could you please help me.

2

Looks like the 10.6 SDK is using a function that’s not available in 10.5, though I’ve never heard of “extractIf” - it’s certainly not used directly by my code, maybe it’s something you’re doing?

3

Thanks, will try to find it out.
I just tried to compile uding GCC 4.0 (instead of GCC 4.2) and all is now working ok… strange…

4

Ah, I bet that the 4.2 compiler was generating that function call internally.

5

so, it is better to use gcc4.0 if i want the plugin to run on 10.4 and 10.5 ?

6

Yes, I think that’s a good idea.

7

thanks! =)

8

Hi,
I have the same problem as described in this thread. When I build some of my plugins using the 10.6 base sdk with gcc 4.2 they run fine under 10.6 but do not pass the auvaltool (and logic) tests under 10.5.
According to the posts above using gcc 4.0 should do the trick but I can’t use the gcc 4.0 version because I’m getting the problems with the atomic ops similar to this thread: http://www.rawmaterialsoftware.com/viewtopic.php?f=8&t=5753.
I’m getting these compile errors:

/Volumes/Data HD/Development/juce/amalgamation/../juce_amalgamated.h:3348: error: cast from 'void*' to 'int32_t' loses precision /Volumes/Data HD/Development/juce/amalgamation/../juce_amalgamated.h: In member function 'bool juce::Atomic<Type>::compareAndSetBool(Type, Type) [with Type = void*]': /Volumes/Data HD/Development/juce/amalgamation/../src/core/juce_SystemStats.cpp:95: instantiated from 'void juce::juce_testAtomicType(Type) [with Type = void*]' /Volumes/Data HD/Development/juce/amalgamation/../src/core/juce_SystemStats.cpp:114: instantiated from here /Volumes/Data HD/Development/juce/amalgamation/../juce_amalgamated.h:3396: error: cast from 'void*' to 'int32_t' loses precision /Volumes/Data HD/Development/juce/amalgamation/../juce_amalgamated.h:3396: error: cast from 'void*' to 'int32_t' loses precision /Volumes/Data HD/Development/juce/amalgamation/../juce_amalgamated.h: In member function 'Type juce::Atomic<Type>::operator+=(Type) [with Type = int*]': /Volumes/Data HD/Development/juce/amalgamation/../src/core/juce_SystemStats.cpp:79: instantiated from 'void juce::juce_testAtomicType(Type) [with Type = int*]' /Volumes/Data HD/Development/juce/amalgamation/../src/core/juce_SystemStats.cpp:115: instantiated from here /Volumes/Data HD/Development/juce/amalgamation/../juce_amalgamated.h:3348: error: cast from 'int*' to 'int32_t' loses precision /Volumes/Data HD/Development/juce/amalgamation/../juce_amalgamated.h: In member function 'bool juce::Atomic<Type>::compareAndSetBool(Type, Type) [with Type = int*]': /Volumes/Data HD/Development/juce/amalgamation/../src/core/juce_SystemStats.cpp:95: instantiated from 'void juce::juce_testAtomicType(Type) [with Type = int*]' /Volumes/Data HD/Development/juce/amalgamation/../src/core/juce_SystemStats.cpp:115: instantiated from here /Volumes/Data HD/Development/juce/amalgamation/../juce_amalgamated.h:3396: error: cast from 'int*' to 'int32_t' loses precision /Volumes/Data HD/Development/juce/amalgamation/../juce_amalgamated.h:3396: error: cast from 'int*' to 'int32_t' loses precision /Volumes/Data HD/Development/juce/amalgamation/../juce_amalgamated.h: In member function 'bool juce::Atomic<Type>::compareAndSetBool(Type, Type) [with Type = juce::juce_wchar*]': /Volumes/Data HD/Development/juce/amalgamation/../juce_amalgamated.h:3335: instantiated from 'Type juce::Atomic<Type>::exchange(Type) [with Type = juce::juce_wchar*]' /Volumes/Data HD/Development/juce/amalgamation/../src/text/juce_String.cpp:214: instantiated from here /Volumes/Data HD/Development/juce/amalgamation/../juce_amalgamated.h:3396: error: cast from 'juce::juce_wchar*' to 'int32_t' loses precision /Volumes/Data HD/Development/juce/amalgamation/../juce_amalgamated.h:3396: error: cast from 'juce::juce_wchar*' to 'int32_t' loses precision

So I’m really stuck because neither gcc 4.2 nor gcc 4.0 work for 10.6 AND 10.5.

I’d prefere the Intel C++ Compiler because of it’s performance benefits but I’m not able to use it because of “-x objective-c++” that is used for the “juce_VST_Wrapper”. This leads to the following warning and the “juce_VST_Wrapper” file is not compiled.

icc: command line warning #10152: option '-x objective-c++' not supported icc: warning #10147: no action performed for specified file(s)

So what can I do to build the universal binaries that work with 10.6 and 10.5 ?

Thanks for your help.

9

I don’t understand your problem with gcc4.0 - I just did a build with it and everything compiles just fine (??) You’re not using an old juce version are you?

10

Well, if you do a i386 build only, you are right and it compiles just fine but if you do a x86_64 build, the errors I posted appear.
Since I need a universal binary running on 10.5 and 10.6 I can’t use gcc 4.0.
I’m using the tip from about two months ago but I don’t think anything regarding the atomics issue has changed since then.
Could you please do a x86_64 build with gcc 4.0 and check if you can reproduce this?
Thanks.

11

nope, a 64-bit intel/gcc4.0 build compiles just fine. I really don’t know what you must be doing that’s different.

12

Damn, you’re right. A lot of things regarding the atomics have changed since the tip I use. Probably it will work with the latest tip.
Unfortunately these changes affect a lot of my custom subclasses. So there’s a lot of work to do…
Thanks anyway.

13

Ok, just in case somebody has the same problem:
For me the problem was not the gcc 4.0. I had to set the base sdk to 10.5 and now it works on 10.5 and 10.6.
The gcc version didn’t make any difference. So setting the base sdk to 10.5 and using gcc 4.2 created universal binaries that work on 10.5 and 10.6.

14

did you try LLVM?

15

I tried the LLVM 1.7 but the result was the same.
The compiler doesn’t matter. It’s the base SDK that makes the problems. Only base SDK 10.5 yields an universal binary that passes the auvaltool on 10.5.
(Forgot to mention that the AU compiled with SDK 10.6 works with AULab on 10.5 but doesn’t pass auvaltool and that’s why it can’t be loaded in logic and live.)

16

After trying everything that came into my mind, I’m still not able to build an AU with Base SDK 10.6 and Deployment Target 10.5 that validates using auvaltool on 10.5.
This is the same for the JuceDemoPlugin.
Jules, have you tried to build the JuceDemoPlugin, so that it validates successfully on 10.5 and 10.6 int the last months?
I could not manage to do that with the DemoPlugin and I’ve tried your default Xcode Project too (as well as many many other settings), except that I changed the Deployment Target to 10.5.
Any help appreciated.

17

Same here.

Auval error on 10.5 if using the 10.6 SDK

Symbol not found: __ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_l Referenced from: /Library/Audio/Plug-Ins/Components/ColorTone.component/Contents/MacOS/ColorTone Expected in: /usr/lib/libstdc++.6.dylib FATAL ERROR: OpenAComponent: result: 4294967246,0xFFFFFFCE

Salvator

18

I think you’re probably best sticking to the 10.5 SDK if you want to deploy to 10.5.