RE: dylib inter-dependencies, install_name_tool and @loader_path
RE: dylib inter-dependencies, install_name_tool and @loader_path
- Subject: RE: dylib inter-dependencies, install_name_tool and @loader_path
- From: Lisa Weimer <email@hidden>
- Date: Thu, 25 Sep 2008 15:29:01 -0600
- Thread-topic: dylib inter-dependencies, install_name_tool and @loader_path
Hey Nicolas,
Yup, should work--evfen with your dylibs in a relative location, as long
as you remember to change the dependency path in the things that need it
to the same path. It should expand it properly at runtime, no matter
where your user relocates your app. Only way to for sure know is to test
it on your app :) In this case one you change everything and package it
up to distribute, it will work the same. I do think there is slightly
different linking options in leopard then were in tiger, at least
through the xcode linker bits, so if you are hooking this up in xcode be
sure to do some reading. But just using install_name_tool to change
things, at least in my experience it just works-- I haven't had any bugs
assigned back to me that trace back to a linking problem that I have
fixed on an app for OS X.
Lisa
-----Original Message-----
From: installer-dev-bounces+lisaweimer=email@hidden
[mailto:installer-dev-bounces+lisaweimer=email@hidden]
On Behalf Of email@hidden
Sent: Thursday, September 25, 2008 3:33 AM
To: email@hidden
Subject: RE: dylib inter-dependencies, install_name_tool and
@loader_path
Hi Lisa,
> I don't know if this will help at all, but hopefully it doesn't cause
> more confusion for you.
Less confusion, and great help indeed :/
Thanks for your answer.
Everything seems OK now.
Indeed, the problem was caused by a dylib loaded at run time : my
executable search path loaded the system-scope library.
One question remains...
> id in install name tool allows you to change the install_name. You can
> read more about install_name in the ld man page. You can set the
> install_name in the Xcode linker options, or you can use
> install_name_tool to change this setting. Install_name (id) is means
> this: things linked against that library will record that path as the
> way dyld should locate that library.
Well, since my dylibs are in a relative location, I've used for them the
id:
@loader_path/MyDyLib.dylib
Would you think that's OK?
Will @loader_path be taken into account, and changed to the actual
absolute path of the loaded library?
As far as I checked, that's OK. But... Who knows...
Best-
Nicolas
> Hi Nicolas,
>
> I've just finished remapping a bunch of frameworks and dylibs for my
> company's applications, so I will take a crack at answering this.
>
> It sounds like your dylib was not relocated properly if it loaded the
> global one first. If you properly relocate things, then the system
will
> always use your copy of whatever was relocated.
>
> I don't know what happens if the copy you want to use doesn't
> exist--that is, I can't confirm that it searches the global system
path
> after trying your path, but based on my linux experience, it wouldn't
> surprise me if that was the default behaviour. (I think if you want it
> to search a specific series of paths, you need to set this behaviour
in
> xcode at linking time using -rpath. I don't know much about doing
things
> in xcode at linking time so I can't help you there.)
>
> id in install name tool allows you to change the install_name. You can
> read more about install_name in the ld man page. You can set the
> install_name in the Xcode linker options, or you can use
> install_name_tool to change this setting. Install_name (id) is means
> this: things linked against that library will record that path as the
> way dyld should locate that library.
>
> @loader_path, as far as I understand it means this: at run time dyld
> replaces @loader_path with the path to the Mach-O binary that loaded
it
> (an executable or another shared library of some sort). Unlike
> @executable_path which only refers to the main executable.
>
> When you changed the ids and references did you use this procedure?
> Use install name tool
> 1. change the id of a.framework (no longer is the system copy)
> 2. change the id of b.framework (no longer is the system copy)
> 3. in a.framework, change the reference to look for your copy of
> b.framework
> (Install_name_tool -change)
> 4. in your exececutable change the references to look for your copies
of
> a.framework and b.framework. (Install_name_tool -change)
>
> You can check all of your work with otool -L, see where and how things
> are referring to each other.
>
> So for your app and libs, the first thing I would do is run otool
> against them all, and verify that things are referring to the right
> things, and also verify the places they are looking actually exist.
>
> I've read before that install_name_tool only works if the new
> install_name (id) is no longer than the old one. But I've never run
into
> this limitation yet, lucky me.
>
> I don't know if this will help at all, but hopefully it doesn't cause
> more confusion for you. Other mail lists that might help are xcode
> development mail lists.
>
> Best,
> Lisa Weimer
>
> -----Original Message-----
> From: installer-dev-bounces+lisaweimer=email@hidden
>
[mailto:installer-dev-bounces+lisaweimer=email@hidden]
> On Behalf Of email@hidden
> Sent: Wednesday, September 24, 2008 7:44 AM
> To: email@hidden
> Subject: Re: dylib inter-dependencies, install_name_tool and
> @loader_path
>
> Hi again,
>
> Indeed, one of the problems was caused by a dynamically dylib loaded
at
> run time (a plugin). The plugin was searched in a global system scope,
> instead
> of being searched inside my distribution.
>
> Hence, as far as checked, using @loader_path/**relative_path_to_B**
> inside a
> .dylib A to refer to a dependent library B behave as following:
>
> 1- if path_of_A/**relative_path_to_B** is existing dylib B is, this
> version of B is loaded
>
> 2- if path_of_A/**relative_path_to_B** is NOT can existing dylib B,
then
> B
> is searched in the global system path.
>
> Is this correct?
>
> Anyhow, my first question is still valid:
>> install_name_tool allows changing the "id" of a dynamic library, with
> -id.
>> But What Does "id" Mean ?
>> And what is the impact of the lib's "id" on loading?
>> I've browsed the doc and the Net for long, but did not find any clear
>> info...
>
>
> Thanks,
> Nicolas
>
>
>
>> Hi folks,
>>
>> I am trying to make my applications distribution for mac OSX.4 and
> X.5,
>> but
>> have a couple of problem with the dynamic loading of libraries.
>>
>>
>> My first question is:
>> install_name_tool allows changing the "id" of a dynamic library, with
> -id.
>> But What Does "id" Mean ?
>> And what is the impact of the lib's "id" on loading?
>> I've browsed the doc and the Net for long, but did not find any clear
>> info...
>>
>>
>> My second question is:
>> What does @loader_path means exactly ?
>> I did not find any clear info on this, and basically, the observed
>> behavior does not match what the doc (apparently) says.
>>
>>
>>
>> Let's now get into a bit more details.
>>
>>
>> My distribution contains various executables, both bundled apps and
>> command-line, that rely on various interdependent libraries. The
> distrib
>> looks like:
>> distrib
>> |_ bin
>> |_ cmdlineexecutable
>> |_ application.app
>> |_ lib
>> |_ A.framework
>> |_ B.framework
>> where both executable depend on A AND B, and where A depends on B.
>>
>>
>> Since the executables are NOT on the same level in the distribution
> tree,
>> using @executable_path inside a library to refer to another library
is
> NOT
>> possible.
>>
>>
>> I guess I have to use @loader_path: the executable would refer to a
>> libraries using @executable_path, and the libraries would refer to
> each
>> others using @loader_path
>>
>>
>> According to the doc:
>>> Library-relative location. To specify a file path relative to
>>> the location of the library itself,
>>> place the @loader_path macro at the beginning of the pathname.
>>
>> However, when using @loader_path, and when the framework is installed
> BOTH
>> inside my distribution AND in a system-searchable location (eg:
>> /Library/Framework) then BOTH versions of a library are loaded when
>> launching the app.
>>
>>
>> I guess that:
>> - the executable, that depends on frameworks A and B refered by using
>> @executable_path, loads the executable-relative versions of the
> frameworks
>> A and B
>> - framework A, that depends on framework B referred by using
> @loader_path,
>> loads the version of B which is located in /Library/Frameworks
>>
>>
>> Hence, @loader_path would NOT refer to the currently-loaded library
>> path... And the doc would lie :/
>>
>>
>> I would appreciate any help on this situation.
>>
>> Thanks much for your attention,
>> best-
>> Nicolas
>>
>> PS: First message on this list. I hope it I picked the correct list.
> Sorry
>> if I was wrong :/
>>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Installer-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> ech.com
>
> This email sent to email@hidden
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Installer-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
imag.fr
>
> This email sent to email@hidden
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Installer-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
ech.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Installer-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden