WINEDLLPATH and /usr/lib/wine

[Ben Klein]

2010/1/26 Michael Ost <most at museresearch.com>:
> Alexandre Julliard wrote:
>> Note that you can always specify the full exe path on the command line.
>
> That doesn't work without a wine drive that includes APP.exe.so --- we run
> without z:/.

This sort of configuration is impossible to support. You should have a
wine drive that includes your APP.exe.so, but that doesn't need to be
the default Z: mapping. What happens if the app wants DLLs from its
own directory?

> I think it makes more sense to require, as Hin-Tak Leung's patch does, that
> a user put /usr/lib/wine in WINEDLLPATH if they use WINEDLLPATH. This is how
> LD_LIBRARY_PATH works for ld and PATH works in bash --- so it's expected
> behavior.

Actually, it's not how LD_LIBRARY_PATH works.
$ LD_LIBRARY_PATH=/path/that/does/not/exist/ /bin/echo Hi there
Hi there

It is the way it works for PATH in all shells (not just bash), but
this is a different matter because your shell environment (often a
login or profile script) provides a default, sensible value for PATH.
$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/games
$ echo $LD_LIBRARY_PATH

WINEDLLPATH should certainly behave more like LD_LIBRARY_PATH than
PATH, but wine should always follow the same DLL search pattern as
Windows. How would Windows handle adding a directory to the DLL search
path? (Is this even possible?)

> Also, from my reading of the code, you jump through some special hoops to
> deal with running from the build directory which could be more easily solved
> by putting WINEDLLPATH first.

How, exactly?

> Anyway, I'm guessing that I'm whistling in the wind here since so much is
> built on how WINEDLLPATH currently works...?
>
> Thanks... mo