WINEDLLPATH and /usr/lib/wine
shacklein at gmail.com
Mon Jan 25 19:40:35 CST 2010
2010/1/26 Michael Ost <most at 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
>>> 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.
More information about the wine-devel