WINEDLLPATH and /usr/lib/wine

[Ben Klein]

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
>>> 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.