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: Wed, 24 Sep 2008 13:43:50 -0000 (GMT)
- Importance: Normal
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:
This email sent to email@hidden