Just updated to the latest version of Juce (and installed both the 10.5 and 10.6 SDK into /Applications/xcode/…) and got into trouble with this (Base SDK 10.6 and 10.5):
_objc_retain referenced from
__ARCLite__load in libarclite_macosx.a(arclite.o)
(maybe you meant: _objc_retainedObject)
Symbol(s) not found for architecture x86_64
A possible solution seems to be to change the build option “Implicitly link Objective C Runtime Support” to “NO” (CLANG_LINK_OBJC_RUNTIME). Does anyone else have this same problem?
When using the 10.6 or 10.7 base SDK the problem disappears.
Does this mean we should really no longer use the 10.5/6 base sdk’s in 5.4.2? I’m just wondering if building with the 10.latest SDK is going to get me into trouble when the app/plugin is run on 10.5/10.6. I know the Base SDK isn’t supposed to create compatibility issues if you don’t use any of the new features in it, but … better safe than sorry.
With this switch both the compilation on xcode 4.5.x with base SDK 10.5 and 10.6 and running on 10.5.8 works.
You possibly never tested your apps on 10.5, if this switch is not off your apps will NOT work on 10.5 even though they build fine with the compatibility SDK set to 10.5.
And the advantage is that you can set the Base SDK to 10.5 as well which could possibly prevent other trouble…
I also can’t find a lot more than you, I’m afraid… I.e. I’m seeing the symtoms, but don’t know what the cure exactly does:
[list]
[](from https://github.com/andymatuschak/Sparkle/commit/d138f64bd6b6a6cc7c20ae7ba683ab81a49e6bd6 ): “Implicitly linking the Obj-C runtime with the 10.7 SDK is causing us to inadvertently reference libblocks symbols, which don’t exist prior to 10.6.”[/]
[]The XCode help: “When linking a target using Objective-C code, implicitly link in Foundation (and if deploying back to an older OS) a backwards compatibility library to allow newer language features to run on an OS where the runtime support is not natively available. Most targets that use Objective-C will want to use this, although there are rare cases where a target may wish to opt out of this behavior.”[/]
[]With CLANG_LINK_OBJC_RUNTIME ON juce binaries built in xcode 4.3 (compatibility sdk 10.5, base sdk 10.7) do not work on 10.5.8 [color=#999999](dyld: Symbol not found: __NSConcreteGlobalBlock at runtime)[/color].[/]
[]With CLANG_LINK_OBJC_RUNTIME ON juce binaries built in xcode 4.3 (compatibility sdk 10.5, base sdk 10.5) do not compile [color=#999999]("_objc_retain referenced from __ARCLite__load in libarclite_macosx.a(arclite.o) (maybe you meant: _objc_retainedObject) Symbol(s) not found for architecture x86_64")[/color].[/]
[]With CLANG_LINK_OBJC_RUNTIME OFF juce binaries built in xcode 4.3 (compatibility sdk 10.5, base sdk 10.7) work on 10.5.8.[/]
[]With CLANG_LINK_OBJC_RUNTIME OFF juce binaries built in xcode 4.3 (compatibility sdk 10.5, base sdk 10.5) compile.[/][/list]
One more reason for leaving CLANG_LINK_OBJC_RUNTIME set to NO is that, if set to YES, it causes obscure EXC_BAD_ACCESS crashes when loading a VST plug-in compiled with Xcode 6, Base SDK = 10.7 and Deployment target = 10.5
Leaving this comment here for future references and to save people days of endless checking for a crash that happens misteriously when none of ones methods are in the callstack ;)
