2010/1/26 Michael Ost <[email protected]>: > 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
