--- On Mon, 25/1/10, Michael Ost most@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:
- 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. 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.