On Jan 19, 2012, at 5:04 PM, Charles Srstka wrote:
> On Jan 19, 2012, at 6:37 PM, John Nairn wrote:
>
>> Well it almost works. I did the following:
>>
>> 1. I took my library (which was already compiled) and renamed it using
>> install_name_tool. It now reports as:
>>
>> DC:<lib>$ otool -D libxerces-c-3.1.dylib
>> libxerces-c-3.1.dylib:
>> @rpath/libxerces-c-3.1.dylib
>>
>> 2. I then compiled my binary and added "@loader_path/lib" to the "Runtime
>> Search Paths" option in XCode build settings for Linking. My binary needs
>> these libraries:
>>
>> DC:<binaries>$ otool -L NairnMPM
>> NairnMPM:
>> @rpath/libxerces-c-3.1.dylib (compatibility version 0.0.0, current
>> version 0.0.0)
>> /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current
>> version 7.9.0)
>> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
>> version 125.2.11)
>>
>> 3. In the Resource folder of my front-end app, I created a "binaries" folder
>> that contains my binary (NairnMPM) and the needed library in a sub folder
>> (lib/libxerces-c-3.1.dylib)
>>
>> 4. My Cocoa app launches the NairnMPM app in the "binaries" folder when
>> needed and that launch needs to find the library.
>>
>> This process seems to be exactly the method I found on various google
>> searches. It seems to work on my Mac (10.6.8) and I even removed my
>> installed /usr/local/lib/libxerces-c-3.1.dylib and it still works. So it
>> appears all is fine.
>>
>> But then I tested on another Mac (10.5.8) and I still get the
>>
>> dyld: unknown required load command 0-x80000022
>>
>> error message with no more help. If I remove the library from my app
>> resource on the 10.6.8 Mac, it does fail but gives a better error message
>> saying where it looked and that the image was not found.
>>
>> My reading said this should all work starting with Leopard, but so far (only
>> testing two machines), I cannot get it to work in Leopard.
>
> Are your app and frameworks all being built as 32-bit/64-bit universal
> binaries, or are they 64-bit only?
>
> Charles
I tried both, but then it occurred to me that the vague error message does not
mean the library has failed to load, but rather that the 10.5.8 Mac was trying
to load an entirely different way (?). I recompiled my binary with deployment
target 10.5 (I had not thought this mattered before because it is plain C++
code that makes no reference to MacOS tools), and now it all works fine.
A clue to the difference is otool on the new binary which is now:
DC:<Default>$ otool -L NairnMPM
NairnMPM:
@rpath/libxerces-c-3.1.dylib (compatibility version 0.0.0, current
version 0.0.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current
version 7.9.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version
697.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 125.2.11)
The last line is new library that gets linked in 10.5 but not in 10.6
Thanks
John Nairn
---------------
John Nairn (1-541-737-4265, FAX:1-541-737-3385)
Professor and Richardson Chair
Web Page: http://www.cof.orst.edu/cof/wse/faculty/Nairn/
FEA/MPM Web Page: http://oregonstate.edu/~nairnj
_______________________________________________
Cocoa-dev mailing list ([email protected])
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [email protected]
