Question

After several hours of experimentation, I’ve managed to reduce the problem to the following example (C++):

extern "C" void foo();

struct test
{
    ~test() { }
};

void doTest()
{
    test t; // 1
    foo();  // 2
}

This is being compiled for iOS devices in XCode 4.2, using the provided Clang compiler (Apple LLVM compiler 3.0) and the iOS 5.0 SDK. The project is configured as a Cocoa Touch Static Library, and “Enable Linking With Shared Libraries” is set to No because I’m building an AIR native extension. The function foo is defined in another external library. (In my actual project, this would be any of the C API functions defined by Adobe for use in AIR native extensions.)

When attempting to compile this code, I get back the error:

FATAL:incompatible feature used: section type non_lazy_symbol_pointers (must specify "-dynamic" to be used)
clang: error: assembler command failed with exit code 1 (use -v to see invocation)

The error goes away if I comment out either of the lines marked 1 or 2 above, or if I change the build setting “Enable Linking With Shared Libraries” to Yes. (However, if I change the build setting, then I get multiple ld warning: unexpected srelocation type 9 warnings when linking the library into the final project, and the application crashes when running on the device.) The build error also goes away if I remove the destructor from test.

So: Is this a bug in Clang? Am I missing some all-important and undocumented build setting? The interaction between an externally-provided function and a struct with a destructor is very peculiar, to say the least.

Answer 1

After much searching, I finally stumbled across Richard Lord’s excellent blog post on AIR native extensions. It turns out that effective development requires use of a few flags that Adobe hasn’t bothered to document yet (unless you count developer blog posts as documentation — I don’t).

Long story short:

• Set “Enable Linking With Shared Libraries” to Yes. Setting this to No is the single most pervasive piece of bad advice out there about developing AIR native extensions.
• Use ADT’s -platformsdk option to point to the iOS SDK provided by Apple (example: -platformsdk /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk). This will alleviate the unexpected srelocation type 9 warnings. Adobe’s documentation states that -platformsdk is only for Android, but that’s a lie.
• When packaging the extension (that is, when building the ANE file), use the undocumented -platformoptions option to specify an xml file containing additional linker arguments. The format of this XML file is also undocumented, but a template can be found in the AIR SDK directory under templates/extensions/ios/platform-descriptor-template.xml. There’s also an xsd schema in the same location. This file allows you to specify whatever additional frameworks your extension uses, so you won’t be limited to the default frameworks that the AIR SDK supports.
• Expect to see a new linker warning: ld: warning: ARM function not 4-byte aligned. This can apparently be safely ignored. Adobe is reportedly aware of the issue. I imagine that you can silence this warning by passing -w to the linker in the platformoptions file, but be aware that -w silences all warnings, not just that one.

Further information can be found in these two blog posts by Rajorshi Ghosh, one of the Adobe engineers:

• iOS5 support for AIR/Using external SDKs to package apps
• Debugging Native Extensions for AIR iOS

This still doesn’t explain the weird interaction between “Enable Linking With Shared Libraries”, externally defined functions, and destructors, but that’s now reduced to a matter of curiosity rather than a blocking issue.