Re: Re[2]: Using a dylib without installing it
Re: Re[2]: Using a dylib without installing it
- Subject: Re: Re[2]: Using a dylib without installing it
- From: "DAS Loop" <email@hidden>
- Date: Thu, 12 Jul 2007 00:00:36 +0200
Now that we don't have a good solution let me introduce another, related, problem: My product has two versions: a GUI and a GUI-less one. The GUI version is on a bundle, the GUI-less is a non-bundle application that will be on, for example, /usr/local/bin . They share a lot of libraries and frameworks.
So far I can solve the bundle problem using the install_name_tool but what about the other application that is not in a bundle? If the user wants to use the GUI-less applications he must to copy somewhere the extra libs ( /usr/lib or /usr/local/lib or /Library/Frameworks/ or ...). But he cannot copy the libraries from the Frameworks bundle in the GUI application as they have been modified with the install_name_tool.
So far the only solution seems to deliver the GUI-less application with another copy of the libraries, this time without any modification and install them in a well know location (what means that I can skip the Frameworks folder in the application bundle :)
Ah! The same applications in Windows are installed in a folder with all the required DLLs. Everything works just fine.
Any good practice on this?
Thanks,
David
On 7/11/07, George Warner <email@hidden> wrote:
On Tue, 10 Jul 2007 18:01:35 -0500, Michael Rice <email@hidden>
wrote:
> If you set the environment variable DYLD_LIBRARY_PATH to include the
> path where your .dylib is located, then you don't have to hard code
> the path into the binary.
Not a robust solution ether since the scope isn't per-.dylib. What if I want
one dylib over there and another somewhere else. Before you say the
DYLIB_LIBRARY_PATH could be a comma separated lists of paths think about
what happens if one of the dylib's exists at both locations (dumb, but it
happens); Which path do you mean for which dylib?
I agree that hard coding the runtime locations into the linking libs is dumb
but the environment variable isn't the solution. The solution would be to be
able to specify the runtime location on the command line at link time (not
when the specific dylib is linked but when dylib(s) that use it are linked).
--
Enjoy,
George Warner,
Schizophrenic Optimization Scientist
Apple Developer Technical Support (DTS)
_______________________________________________
Do not post admin requests to the list. They will be ignored.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden