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