WINEDLLPATH and /usr/lib/wine
shacklein at gmail.com
Tue Jan 26 07:34:20 CST 2010
2010/1/26 Hin-Tak Leung <hintak_leung at yahoo.co.uk>:
> --- On Mon, 25/1/10, Michael Ost <most at museresearch.com> wrote:
>> Alexandre Julliard wrote:
>> > Not necessarily, the behavior could probably be
>> tweaked, feel free to
>> > suggest changes. You can't require users to set
>> WINEDLLPATH for normal
>> > usage though, including running from the build tree or
>> from a relocated
>> > install.
>> Two easy options would be:
>> 1. put /usr/lib/wine at the end of the list automatically.
>> This is Hin-Tak Leung's approach.
>> 2. require users to add /usr/lib/wine themselves. I could
>> make a patch for that.
>> #1 is easier for me :) but #2 is a little more "standard",
>> acting like LD_LIBRARY_PATH or PATH do.
>> Which would you prefer? ... mo
> If I understand that bit of code correctly, the current behavior is such that built-ins comes before WINEDLLPATH *and* after, so there is no way a user per-application built-ins can override (even temporarily on a per application basis) the system-wide built-ins.
> As ddiwrapper - the application I was interested in - tried to provide a gdl32.dll.so which does different things - it stopped working when the system-wide built-ins is both prepended and appended to library search.
For DLLs at least, you should be able to rename the .dll.so to a .dll
and stick it in the application's directory. I don't recall the last
time I tried this, but it certainly worked (I was using a hacked
ddraw.dll.so to get Diablo and Worms Armageddon playing nicely). I
assume you could do something similar for EXEs.
> I think it should work like LD_LIBRARY_PATH, really as they are platform shared libraries.
> There is, of course a rather absurd way of working around the current situation - cross-compilating the override desired as win32 PE's (then
> WINEDLLOVERRIDES does work) - but this doesn't quite work, for things like ddiwrapper again, as it actually wants to do host-native (linux-) things, rather than win32-only things.
Is there some specific reason why you *need* WINEDLLPATH to override
standard built-ins? Is your APP.exe.so being called by some other
process that does not specify the full path, or something along those
More information about the wine-devel