iPhone靜態庫鏘/ LLVM錯誤：non_lazy_symbol_pointers

後幾個小時的實驗，我已經成功地減少的問題，以下面的例子中（C++）：iPhone靜態庫鏘/ LLVM錯誤：non_lazy_symbol_pointers

extern "C" void foo(); 

struct test 
{ 
    ~test() { } 
}; 

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

這被編譯爲在XCode中iOS設備4.2，使用提供的Clang編譯器（Apple LLVM編譯器3.0）和iOS 5.0 SDK。該項目配置爲Cocoa Touch靜態庫，並且「啓用與共享庫的鏈接」設置爲「否」，因爲我構建的是AIR本機擴展。功能foo在另一個外部庫中定義。（在我的實際項目，這將是任何由Adobe爲AIR本機擴展使用所定義的C API函數）。

當試圖編譯這段代碼，我回來了錯誤：

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)

如果我將以上標記爲1或2的行註釋掉，或者將構建設置「啓用與共享庫的鏈接」更改爲「是」，則錯誤消失。（但是，如果我更改了構建設置，那麼在將庫鏈接到最終項目時會出現多個ld warning: unexpected srelocation type 9警告，並且在設備上運行時應用程序會崩潰。）如果從test刪除析構函數，構建錯誤也會消失。

所以：這是叮噹中的錯誤嗎？我是否錯過了一些非常重要且沒有記錄的構建設置？至少可以說，外部提供的函數和具有析構函數的結構之間的交互是非常奇特的。

來源

2012-03-15 Bekenn

經過多次搜索，我終於偶然發現理查德勳爵的excellent blog post on AIR native extensions。事實證明，有效的開發需要使用Adobe尚未記錄的幾個標誌（除非您將開發人員博客文章計爲文檔 - 我不這麼做）。

長話短說：

設置了「啓用鏈接共享庫」爲是。將此設置爲No是開發AIR原生擴展的最普遍的一個壞建議。
使用ADT的-platformsdk選項指向Apple提供的iOS SDK（例如：-platformsdk /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk）。這將緩解unexpected srelocation type 9警告。 Adobe的文檔指出-platformsdk僅適用於Android，但這是謊言。
打包擴展名（即構建ANE文件時），請使用未公開的-platformoptions選項來指定包含其他鏈接器參數的xml文件。此XML文件的格式也未記錄，但可以在AIR SDK目錄下的templates/extensions/ios/platform-descriptor-template.xml下找到模板。在同一位置還有一個xsd模式。該文件允許您指定您的擴展使用的任何其他框架，因此您不會受限於AIR SDK支持的默認框架。
預計會看到新的鏈接警告：ld: warning: ARM function not 4-byte aligned。這顯然可以安全地忽略。據報道，Adobe意識到這個問題。我想你可以通過將-w傳遞給platformoptions文件中的鏈接器來消除此警告，但請注意-w會將全部都警告，而不僅僅是那一個。

更多信息可以在這兩個博客文章由Rajorshi戈什，Adobe的工程師的一個發現：

這仍然沒有解釋「啓用與共享庫鏈接」，外部定義的函數和析構函數之間的奇怪交互，但現在已經降低到好奇心而不是阻塞問題即

來源

2012-03-17 00:08:18 Bekenn

我在非AIR情況下遇到了同樣的問題。主要問題是你的第一個項目符號和設置，共享鏈接到是解決了問題。 – 2012-03-28 04:35:45

iPhone靜態庫鏘/ LLVM錯誤：non_lazy_symbol_pointers

回答

相關問題