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