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: email@hidden
- Date: Thu, 25 Sep 2008 09:32:46 -0000 (GMT)
- Importance: Normal
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:
>
> 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