2010/1/26 Michael Ost <m...@museresearch.com>: > Ben Klein wrote: >> 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?) > > I'm not getting why Windows DLL searching is relevant here. This is a > Linux-side issue.
Because Wine has to emulate Windows behaviour, whether it's unix-like behaviour or not. >>> 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? > > This was a slightly uninformed comment on my part, so I could be totally off > base here. And the code supporting dll directory lookups is complicated. But > ... I saw special cases for dealing with the build directory, including this > comment "/* if no build dir skip all the build dir magic cases */" > libs/wine/loader.c/first_dll_path. Those suggest to me that someone was > trying to stick a path in before /usr/lib/wine. Yes, this is specifically so that you can test wine from a build directory without having to install it. Without this, regression testing would be virtually impossible. I don't see how sticking WINEDLLPATH at the top of the list will help. > All that said, this isn't at all central to what I would like to do. All I > want is that WINEDLLPATH comes before /usr/lib/wine. > > - mo > > PS: Hin-Tak Leung, who got bit by this before me, found that WINEDLLPATH > broke/changed in November of 2006. There are other ways to acheive what you're trying to do, like setting up a wine drive that points to wherever you're developing your custom APP.exe.so and specifying the complete path on the commandline.