Re: codesign vs. install_name_tool
Re: codesign vs. install_name_tool
- Subject: Re: codesign vs. install_name_tool
- From: Jeff Johnson <email@hidden>
- Date: Thu, 23 Feb 2012 11:35:14 -0600
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