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.
On Jan 19, 2012, at 1:31 PM, Charles Srstka wrote:
> On Jan 19, 2012, at 3:25 PM, Jens Alfke wrote:
>
>> You can avoid having to set that variable if you change the dylib’s install
>> name — that way targets that link against it will remember a more
>> appropriate path, like a relative path. You can use “@executable_path” in
>> which case the library will be looked for in the same directory as the
>> executable. You can do this in Xcode in the build settings for the library,
>> or you can also edit the copy of the library you include in your app, via a
>> build script — I don’t know exactly what tool is used to edit the install
>> name, but I’m guessing libtool.
>
> If you don’t need to be compatible with OS X 10.4 or earlier, @rpath is
> probably a better way to go than @executable_path.
>
> Charles
---------------
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [email protected]
