名爲.dylib不能用Xcode的應用程序

我已經建立了一個32位的dylib的OS X與德爾福XE2 UPD使用。 3.它的安裝名稱使用@rpath。所有導出都以下劃線開頭，並通過otool進行驗證。出口在Delphi中使用「cdecl」調用約定。名爲.dylib不能用Xcode的應用程序

我不能得到這個dylib與OS X 10.7.3運行在Xcode 4.3 32位主機應用程序的工作。當我在Xcode中運行測試項目，它停止與調用調用堆棧的lib和dyld_start。

enter image description here

當我運行從搜索這個應用程序（從用戶庫中的Xcode的文件夾），我得到的圖像不從dyld的找到錯誤。

我已經添加了副本構建階段，其副本（它需要和libcgunwind.1.0.dylib）的dylib進入產品目錄。我還將Runpath Search Paths設置爲@executable_path或@loader_path，都無濟於事。

的方法是通過

extern int TestLib(int AInt);

庫中導入是最小的，因爲它可以得到，只是包含此單元：

unit LibTestExports; 

uses 
    System.Classes, 
    System.SysUtils; 

function _TestLib(AInt: Integer): Integer; export; cdecl; 
begin 
    Result:= AInt + 2; 
end; 

exports 
    _TestLib; 

end.

我出的是什麼原因造成這樣的想法和我如何才能讓這個工作。

Xcode項目和庫可以在這裏找到：http://dl.dropbox.com/u/17403534/CAS4LibTest.zip

UPDATE：這個問題似乎是獅子專用！它使用Xcode 4.2在Snow Leopard 10.6.4中正常工作。（Lion上的Xcode 4.2會導致同樣的問題）

在FireMonkey應用程序使用Lion時，同樣的dylib也可以正常工作（這些方法是使用external 'libName'靜態導入的）。

運行獅子在相同的應用程序，即雪豹下正常工作，我得到一個包含以下調用堆棧崩潰報告：

0 ???        0x0013317c 0 + 1257852 
1 libCAS4.dylib     0x00010b5c @DbgEvalFrame + 1648 
2 libCAS4.dylib     0x00010e1a @DbgEvalFrame + 2350 
3 dyld       0x8fe55203 ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) + 251 
4 dyld       0x8fe54d68 ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) + 64 
5 dyld       0x8fe522c8 ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&) + 256 
6 dyld       0x8fe5225e ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&) + 150 
7 dyld       0x8fe53268 ImageLoader::runInitializers(ImageLoader::LinkContext const&, ImageLoader::InitializerTimingList&) + 62 
8 dyld       0x8fe47694 dyld::initializeMainExecutable() + 214 
9 dyld       0x8fe4bf99 dyld::_main(macho_header const*, unsigned long, int, char const**, char const**, char const**) + 2238 
10 dyld       0x8fe452ef dyldbootstrap::start(macho_header const*, int, char const**, long, macho_header const*) + 637 
11 dyld       0x8fe45063 _dyld_start + 51

解決方法： Embarcadero的支持，現在有一種變通方法，修復回來我的問題：在System.Classes的本地副本GlobalNameSpace的聲明中更改：IReadWriteSync到合適的班級在初始化部分使用。

來源

2012-02-13 msohn

nm：對象：libLibTest.dylib格式錯誤的對象（偏移量爲509728的間接表，大小爲576，與偏移量爲507904的段內容重疊，大小爲67082） ...測試庫是否有效？ – Petesh 2012-02-13 19:21:16

我希望圖書館是有效的，但我不確定。如果不是這樣，那意味着Delphi XE2會被嚴重破壞，因爲這是最基本的代碼轉換成庫。其實我也注意到nm認爲這個庫是無效的，但後來看到otool輸出的輸出很好。 – msohn 2012-02-13 22:28:58

請記住，nm，otool和dyld使用不同的代碼來讀取文件中的相關元素。 nm的抱怨可能是dyld調用失敗的原因。我使用IDA來反彙編TestLib調用，它看起來像一個int *作爲參數，而不是int。這會在調用時導致訪問衝突的副作用;但它看起來像之前發生的錯誤（在圖書館加載時間） – Petesh 2012-02-14 09:08:51

您正在構建的庫對bplrtl160.dylib有一個隱式依賴關係，您需要將其與應用程序捆綁在一起 - 您應該確保該庫是使用運行時包創建的。

有某種形式的初始化神奇，當你建立與德爾福XE2的可執行文件，當你下建立Xcode中的應用，這是造成問題不會發生這種情況發生;可能是一些鏈接到應用程序中的初始化代碼，該應用程序在創建爲庫時未鏈接到該應用程序。

你所得到的實際的例外是：

@[email protected]@IReadWriteSync

這是在bplrtl160.dylib負荷時間發生的事情（即這一點你甚至不會與圖書館交流）。這是一個應該在應用程序加載時初始化的接口類。

如果您從庫文件的uses子句中刪除System.SysUtils, System.Classes條目，那麼它實際上會加載庫;但這意味着您從XE2構建的任何庫都不能使用類和sysutils代碼;這使得它比適合使用少一點。

至於修復;我不知道。可能根本沒有修復。

來源

2012-02-14 19:07:22 Petesh

非常感謝，我能夠使用uses子句中沒有RTL單元的lib來運行它。但正如你所提到的那樣，這並沒有多大用處。 – msohn 2012-02-15 12:43:18

如果我啓用了運行時包，那麼我會對RTL包產生依賴關係，這很清楚。但是爲什麼我要編譯RTL到dylib？如果我不使用運行時軟件包編譯，那麼將rtl dylib放入Products目錄中並沒有什麼區別。 – msohn 2012-02-15 12:47:17

如果啓用運行時軟件包，然後不使用任何代碼，則代碼將不會鏈接到bpl160.dylib，從而不會崩潰。靜態鏈接時，它將編譯爲bpl160.dylib的靜態等價物，這會在加載庫時觸發問題。您可以通過使用-lazy-lLTTest鏈接測試庫來獲得更好的堆棧跟蹤，這會導致首次調用導出的函數時發生問題（這是我跟蹤問題的方式）。使用共享軟件包的原因是在Windows下類似於運行時問題的習慣。 – Petesh 2012-02-15 13:18:28

名爲.dylib不能用Xcode的應用程序

回答

相關問題