WINEDLLPATH and /usr/lib/wine
shacklein at gmail.com
Mon Jan 25 18:35:50 CST 2010
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
> 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
Actually, it's not how LD_LIBRARY_PATH works.
$ LD_LIBRARY_PATH=/path/that/does/not/exist/ /bin/echo 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
$ 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.
> Anyway, I'm guessing that I'm whistling in the wind here since so much is
> built on how WINEDLLPATH currently works...?
> Thanks... mo
More information about the wine-devel