2010/1/26 Michael Ost most@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