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: Wed, 24 Sep 2008 13:31:36 -0600
- Thread-topic: dylib inter-dependencies, install_name_tool and @loader_path
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