RE: codesign vs. install_name_tool
RE: codesign vs. install_name_tool
- Subject: RE: codesign vs. install_name_tool
- From: "Dallman, John" <email@hidden>
- Date: Thu, 23 Feb 2012 17:53:41 +0000
- Thread-topic: codesign vs. install_name_tool
> Use @rpath/mylib.dylib for the install name. Then application developers
> can use LD_RUNPATH_SEARCH_PATHS in their build settings to find your library.
This looks interesting, but I don't speak Xcode IDE - my sight is quite poor,
and IDEs don't work well for me.
https://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/RunpathDependentLibraries.html#//apple_ref/doc/uid/TP40008306-SW1
If I'm following you correctly, LD_RUNPATH_SEARCH_PATHS is a macro in Xcode that
gets expanded to one or more -rpath options to ld when building the executable?
Those rpath options store strings in the executable for the dylamic loader to
use at load time? If so, then yes, I should be able to solve the problem that way.
Thanks!
--
John Dallman
-----Original Message-----
From: Jeff Johnson [mailto:email@hidden]
Sent: 23 February 2012 17:35
To: Dallman, John
Cc: xcode-Users List
Subject: Re: codesign vs. install_name_tool
Hi John.
Use @rpath/mylib.dylib for the install name. Then application developers can use LD_RUNPATH_SEARCH_PATHS in their build settings to find your library.
-Jeff
On Feb 23, 2012, at 8:41 AM, Dallman, John wrote:
> The products I work on are not applications. They are libraries, which are
> commercial closed-source software, distributed in binary form. They are
> licensed by a variety of ISVs, and used in several assorted and unrelated
> Mac OS X applications.
>
> Those apps all have their own copies of my libraries. They need to have
> their own copies, rather than sharing them, because some of them use
> different versions or different licenses. So the libraries do not form a
> framework or bundle (the headers aren't delivered to end-users), and there
> is no canonical place in the filesystem where these apps put my libraries;
> they each have their own place, and many of them put it somewhere different
> in each version of their app.
>
> So my customers need to use install_name_tool to set the install names of
> my libraries. This works OK so far, but with gatekeeper forthcoming in
> Mountain Lion, there will be pressure to sign my libraries. I can do that,
> but the problem is that changing the install name with install_name_tool
> breaks the signature.
>
> Is there a way to avoid this? I can't see one in the codesign options,
> or via some Googling, but it seemed worth asking.
>
> I can see an argument that allowing install_name_tool to not break the
> signature opens up devious paths for hackery. But it also seems pretty
> clear that Apple are thinking about complete apps, rather than libraries.
>
> My fallback is to use an install name based on @loader_path, which will
> probably do for most of my customers. But it's hard to be sure it will
> do for all of them; they can be quite creative in their application
> designs.
>
> thanks,
>
> --
> John Dallman
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden