install_name_tool
-
Hi,
I can't figure out how install_name_tool works.
I've tried it with the simplest project ever:
1. I've created a blank "Foo" framework in Xcode
2. I've built it with the "-headerpad_max_install_names" linker flag
(as man install_name_tool says)
3. I do this in the terminal :
$ otool -L Foo
/Users/martin/Library/Frameworks/Foo.framework/Versions/A/Foo
(compatibility version 1.0.0, current version 1.0.0)
...
$ install_name_tool -change "/Users/martin/Library/Frameworks/
Foo.framework/Versions/A/Foo" "bla" Foo
$ otool -L Foo
/Users/martin/Library/Frameworks/Foo.framework/Versions/A/Foo
(compatibility version 1.0.0, current version 1.0.0)
...
And as you can see, nothing has changed and the first line has
certainly not been replaced by "bla". What am I doing wrong?
Thanks,
Martin. -
On Thu, Jun 19, 2008 at 4:40 PM, Martin <martin.cocoa...> wrote:> And as you can see, nothing has changed and the first line has certainly not
> been replaced by "bla". What am I doing wrong?
Shouldn't you be using the -id flag, not -change?
--Kyle Sluder -
Le 19 juin 08 à 23:02, Kyle Sluder a écrit :> On Thu, Jun 19, 2008 at 4:40 PM, Martin <martin.cocoa...>
> wrote:
>> And as you can see, nothing has changed and the first line has
>> certainly not
>> been replaced by "bla". What am I doing wrong?
>
> Shouldn't you be using the -id flag, not -change?
>
> --Kyle Sluder
And generaly, it's easier to just change the "installation path" in
build settings at first, but maybe you are in a situation that prevent
you to do it the easy way. -
On Jun 19, 2008, at 11:02 PM, Kyle Sluder wrote:> On Thu, Jun 19, 2008 at 4:40 PM, Martin <martin.cocoa...>
> wrote:
>> And as you can see, nothing has changed and the first line has
>> certainly not
>> been replaced by "bla". What am I doing wrong?
>
> Shouldn't you be using the -id flag, not -change?
>
I usually do both of them (for framework embedding). E.g to make a
framework embeddable
install_name_tool -change /Library/Frameworks/$EXECUTABLE_PATH
@executable_path/../Frameworks/$EXECUTABLE_PATH $EXECUTABLE_NAME
install_name_tool -id @executable_path/../Frameworks/
$EXECUTABLE_PATH $EXECUTABLE_NAME
I think one option is about install path while the other is about
identification
laurent -
Thanks for your answers but it's still not working here. Plus I don't
really see why I should use "-id" option since what I really want to
do is *change* one of the paths.
Back to my Foo framework:
$ otool -L Foo.framework/Foo
/Users/martin/Library/Frameworks/Foo.framework/Versions/A/Foo
(compatibility version 1.0.0, current version 1.0.0)
...
$ install_name_tool -change /Users/martin/Library/Frameworks/
Foo.framework/Versions/A/Foo @executable_path../../Frameworks/
Foo.framework/Versions/A/Foo Foo.framework/Foo
$ otool -L Foo.framework/Foo
/Users/martin/Library/Frameworks/Foo.framework/Versions/A/Foo
(compatibility version 1.0.0, current version 1.0.0)
...
Am I typing something wrong? Does it work on your computer?
There are no error messages given by install_name_tool, it just
silently does nothing...
Martin.
On Jun 19, 2008, at 11:56 PM, Laurent Cerveau wrote:>
> On Jun 19, 2008, at 11:02 PM, Kyle Sluder wrote:
>
>> On Thu, Jun 19, 2008 at 4:40 PM, Martin <martin.cocoa...>
>> wrote:
>>> And as you can see, nothing has changed and the first line has
>>> certainly not
>>> been replaced by "bla". What am I doing wrong?
>>
>> Shouldn't you be using the -id flag, not -change?
>>
>
> I usually do both of them (for framework embedding). E.g to make a
> framework embeddable
>
> install_name_tool -change /Library/Frameworks/$EXECUTABLE_PATH
> @executable_path/../Frameworks/$EXECUTABLE_PATH $EXECUTABLE_NAME
> install_name_tool -id @executable_path/../Frameworks/
> $EXECUTABLE_PATH $EXECUTABLE_NAME
>
> I think one option is about install path while the other is about
> identification
>
> laurent
> -
You don't want to change the path, you want to change the id of your
library.
-change is intended to be used to change the path of a dependent
library in an other binary.
install_name_tool -id @executable_path../../Frameworks/Foo.framework/
Versions/A/Foo Foo.framework/Foo
But as I said, it's easier to change that in your Xcode build settings
instead.
Le 20 juin 08 à 09:12, Martin a écrit :> Thanks for your answers but it's still not working here. Plus I
> don't really see why I should use "-id" option since what I really
> want to do is *change* one of the paths.
> Back to my Foo framework:
>
> $ otool -L Foo.framework/Foo
> /Users/martin/Library/Frameworks/Foo.framework/Versions/A/Foo
> (compatibility version 1.0.0, current version 1.0.0)
> ...
>
> $ install_name_tool -change /Users/martin/Library/Frameworks/
> Foo.framework/Versions/A/Foo @executable_path../../Frameworks/
> Foo.framework/Versions/A/Foo Foo.framework/Foo
>
> $ otool -L Foo.framework/Foo
> /Users/martin/Library/Frameworks/Foo.framework/Versions/A/Foo
> (compatibility version 1.0.0, current version 1.0.0)
> ...
>
> Am I typing something wrong? Does it work on your computer?
> There are no error messages given by install_name_tool, it just
> silently does nothing...
>
> Martin.
>
> On Jun 19, 2008, at 11:56 PM, Laurent Cerveau wrote:
>
>>
>> On Jun 19, 2008, at 11:02 PM, Kyle Sluder wrote:
>>
>>> On Thu, Jun 19, 2008 at 4:40 PM, Martin <martin.cocoa...>
>>> wrote:
>>>> And as you can see, nothing has changed and the first line has
>>>> certainly not
>>>> been replaced by "bla". What am I doing wrong?
>>>
>>> Shouldn't you be using the -id flag, not -change?
>>>
>>
>> I usually do both of them (for framework embedding). E.g to make a
>> framework embeddable
>>
>> install_name_tool -change /Library/Frameworks/$EXECUTABLE_PATH
>> @executable_path/../Frameworks/$EXECUTABLE_PATH $EXECUTABLE_NAME
>> install_name_tool -id @executable_path/../Frameworks/
>> $EXECUTABLE_PATH $EXECUTABLE_NAME
>>
>> I think one option is about install path while the other is about
>> identification
>>
>> laurent
>>
> -
On Thu, Jun 19, 2008 at 5:56 PM, Laurent Cerveau <lcerveau...> wrote:>
> On Jun 19, 2008, at 11:02 PM, Kyle Sluder wrote:
>
>> On Thu, Jun 19, 2008 at 4:40 PM, Martin <martin.cocoa...> wrote:
>>>
>>> And as you can see, nothing has changed and the first line has certainly
>>> not
>>> been replaced by "bla". What am I doing wrong?
>>
>> Shouldn't you be using the -id flag, not -change?
>
> I usually do both of them (for framework embedding). E.g to make a framework
> embeddable
Usually? I smell a cargo cult.> install_name_tool -change /Library/Frameworks/$EXECUTABLE_PATH
> @executable_path/../Frameworks/$EXECUTABLE_PATH $EXECUTABLE_NAME
> install_name_tool -id @executable_path/../Frameworks/$EXECUTABLE_PATH
> $EXECUTABLE_NAME
>
> I think one option is about install path while the other is about
> identification
The man page says exactly what the options are for, no thought
required. :-) The -id option sets the install name for a framework.
The -change option is used when you want to modify something that's
been linked to the framework.
sherm--
--
Cocoa programming in Perl: http://camelbones.sourceforge.net -
On Fri, Jun 20, 2008 at 3:12 AM, Martin <martin.cocoa...> wrote:>
> Thanks for your answers but it's still not working here. Plus I don't really
> see why I should use "-id" option since what I really want to do is *change*
> one of the paths.
Straight from "man install_name_tool":
-change old new
Changes the dependent shared library install name old to new in
the specified Mach-O binary. More than one of these options can
be specified. If the Mach-O binary does not contain the old
install name in a specified -change option the option is
ignored.
-id name
Changes the shared library identification name of a dynamic
shared library to name. If the Mach-O binary is not a dynamic
shared library and the -id option is specified it is ignored.
You *have* read the man page for the tool you're using, right? :-)> $ install_name_tool -change
> /Users/martin/Library/Frameworks/Foo.framework/Versions/A/Foo
> @executable_path../../Frameworks/Foo.framework/Versions/A/Foo
> Foo.framework/Foo
What you're doing here is, wherever Foo.framework/Foo is *linked to* a
dependent shared library at the first path, change that reference to
refer to the second path instead. That is, the -change option doesn't
change the install name of the target. It changes the target's
references to *other* libraries.
If any applications have linked against your framework using the old
install_name, you could use the -change option to update the apps'
references to your framework.> There are no error messages given by install_name_tool, it just silently
> does nothing...
That's what it's documented to, when -change is used and
Foo.framework/Foo has no external references to the given path.
As others have suggested, the easiest way to set the install name for
a framework is to "get info" on the target in Xcode and enter it
there. That's simple, automatic, and painless. That said, if the above
is copy & pasted, and its the same path you tried with the -id option,
you're missing a slash after @executable_path, and looking a directory
too far up the tree. It should be:
install_name_tool -id
@executable_path/../Frameworks/Foo.framework/Versions/A/Foo
Suggested reading:
<http://developer.apple.com/documentation/Darwin/Reference/ManPages/man1/ins
tall_name_tool.1.html>
<http://developer.apple.com/documentation/MacOSX/Conceptual/BPFrameworks/Tas
ks/CreatingFrameworks.html>
- especially the section titled "Embedding a Private Framework in Your
Application Bundle".
sherm--
--
Cocoa programming in Perl: http://camelbones.sourceforge.net -
Sometimes you just need someone to tell you to read *again* the man
page and actually try to understand what the words mean ;-)
Thanks Sherm!
-Martin
On Jun 20, 2008, at 12:25 PM, Sherm Pendley wrote:> On Fri, Jun 20, 2008 at 3:12 AM, Martin <martin.cocoa...>> >
> wrote:
>>
>> Thanks for your answers but it's still not working here. Plus I
>> don't really
>> see why I should use "-id" option since what I really want to do is
>> *change*
>> one of the paths.
>
> Straight from "man install_name_tool":
>
> -change old new
> Changes the dependent shared library install name old
> to new in
> the specified Mach-O binary. More than one of these
> options can
> be specified. If the Mach-O binary does not contain
> the old
> install name in a specified -change option the
> option is
> ignored.
>
> -id name
> Changes the shared library identification name of
> a dynamic
> shared library to name. If the Mach-O binary is not
> a dynamic
> shared library and the -id option is specified it is
> ignored.
>
> You *have* read the man page for the tool you're using, right? :-)
>
>> $ install_name_tool -change
>> /Users/martin/Library/Frameworks/Foo.framework/Versions/A/Foo
>> @executable_path../../Frameworks/Foo.framework/Versions/A/Foo
>> Foo.framework/Foo
>
> What you're doing here is, wherever Foo.framework/Foo is *linked to* a
> dependent shared library at the first path, change that reference to
> refer to the second path instead. That is, the -change option doesn't
> change the install name of the target. It changes the target's
> references to *other* libraries.
>
> If any applications have linked against your framework using the old
> install_name, you could use the -change option to update the apps'
> references to your framework.
>
>> There are no error messages given by install_name_tool, it just
>> silently
>> does nothing...
>
> That's what it's documented to, when -change is used and
> Foo.framework/Foo has no external references to the given path.
>
> As others have suggested, the easiest way to set the install name for
> a framework is to "get info" on the target in Xcode and enter it
> there. That's simple, automatic, and painless. That said, if the above
> is copy & pasted, and its the same path you tried with the -id option,
> you're missing a slash after @executable_path, and looking a directory
> too far up the tree. It should be:
>
> install_name_tool -id
> @executable_path/../Frameworks/Foo.framework/Versions/A/Foo
>
> Suggested reading:
>
> <http://developer.apple.com/documentation/Darwin/Reference/ManPages/man1/ins
tall_name_tool.1.html
> >> - especially the section titled "Embedding a Private Framework in Your
> Application Bundle".
>
> sherm--
>
> --
> Cocoa programming in Perl: http://camelbones.sourceforge.net
