2010/1/26 Hin-Tak Leung <[email protected]>: > --- On Mon, 25/1/10, Michael Ost <[email protected]> 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 lines?
