suggestions about MacOS DYLD_FALLBACK_LIBRARY_PATH patch

Emmanuel Maillard mahanuu at free.fr
Thu Jul 16 06:18:09 CDT 2009


Le 15 juil. 09 à 20:06, Steven Edwards a écrit :

> On Wed, Jul 15, 2009 at 11:11 AM, Emmanuel Maillard<mahanuu at free.fr>  
> wrote:
>>> Since OS X does not provide some of the libraries that we need,  
>>> should
>>> we have a dependency build script that installs those libraries to a
>>> standard location (so the users don't need to install MacPorts of  
>>> Fink
>>> just to get Wine) or should we ask them to go mucking with the
>>> ~/.bashrc? If we want to provide a Winehq support Wine package for  
>>> OS
>>> X we have to decide on a configuration that will work and be the  
>>> least
>>> invasive to the users when they go to install.
>>>
>>
>> That was the goal of Wine.bundle in Darwine.
>
> Austin has updated the dependency build script and we've been using it
> on my box to build the required libraries but they are not together in
> a bundle, hence the need for the LD_LIBRARY_PATH or
> DYLD_FALLBACK_LIBRARY_PATH changes. What do you think is the best way
> to resolve this issue? My interest is that I'd like to provide binary
> packages of Winehq releases however this issue is a real pain. I
> suppose we could also provide a support package that is separate from
> the stock Wine package which would supply the missing libraries or
> whatnot.
>

If you build your package in standard path (/usr/local for example)  
you may not
need DYLD_FALLBACK_LIBRARY_PATH (see man dyld for default path).

If you make a complete bundle for Wine, you'll need it, but it may be  
set dynamically,
while initializing wine lib, see get_runtime_libdir.

Now using a bundle or an installer for packing Wine ? IMHO bundles are  
more friendly
to end users.

Emmanuel

> Thanks
> -- 
> Steven Edwards
>
> "There is one thing stronger than all the armies in the world, and
> that is an idea whose time has come." - Victor Hugo




More information about the wine-devel mailing list