find_dll_file ignoring WINEDLLPATH?

[Erik de Castro Lopo]

Hi all,

I have a windows executable named floating_point_test.exe which
requires a windows DLL that is in another directory. I'm trying
to run the exe from the current dir using:

WINEDLLPATH="/path/to/dll:$WINEDLLPATH" wine floating_point_test.exe

but wine is not able to find the DLL. I've traced through the code
and ended up in the file dlls/ntdll/loader.c and the function
find_dll_file (). I've added a few printfs and found that when
looking for my DLL, the code ends up in a section with the following
comment:

/* if libname doesn't contain a path at all, we simply return the name as is,
     * to be loaded as builtin */

It seems that this function makes no use of WINEDLLPATH. Shouldn't
this function also search along the paths specified by the
environment variable?

Cheers,
Erik

[Erik de Castro Lopo]

Erik de Castro Lopo wrote:
> It seems that this function makes no use of WINEDLLPATH. Shouldn't
> this function also search along the paths specified by the
> environment variable?

I've grepped the sources and the only place that looks at 
WINEDLLPATH is the funcion build_dll_path() in libs/wine/loader.c.

The function build_dll_path() fills in an array dll_paths with
is private to that file. Looking at other things in that file
it seems that stuff in that file is mostly related to loading
the native Linux versions of the windows DLLs. Is that right?
If so, it looks like some of the code in libs/wine/loader.c
needs to be cloned or shared with the code in
dlls/ntdll/loader.c.

I'm willing to hack up a fix for this if someone can point me
in the right direction.

Cheers,
Erik

[Erik de Castro Lopo]

Erik de Castro Lopo wrote:
> It seems that this function makes no use of WINEDLLPATH. Shouldn't
> this function also search along the paths specified by the
> environment variable?

I've grepped the sources and the only place that looks at 
WINEDLLPATH is the funcion build_dll_path() in libs/wine/loader.c.

The function build_dll_path() fills in an array dll_paths with
is private to that file. Looking at other things in that file
it seems that stuff in that file is mostly related to loading
the native Linux versions of the windows DLLs. Is that right?
If so, it looks like some of the code in libs/wine/loader.c
needs to be cloned or shared with the code in
dlls/ntdll/loader.c.

I'm willing to hack up a fix for this if someone can point me
in the right direction.

Cheers,
Erik

[John Klehm]

On Sat, Mar 29, 2008 at 9:31 PM, Erik de Castro Lopo
 wrote:
> Erik de Castro Lopo wrote:
> > It seems that this function makes no use of WINEDLLPATH. Shouldn't
> > this function also search along the paths specified by the
> > environment variable?
>
> I've grepped the sources and the only place that looks at
>  WINEDLLPATH is the funcion build_dll_path() in libs/wine/loader.c.
>
> The function build_dll_path() fills in an array dll_paths with
>  is private to that file. Looking at other things in that file
>  it seems that stuff in that file is mostly related to loading
>  the native Linux versions of the windows DLLs. Is that right?
>  If so, it looks like some of the code in libs/wine/loader.c
>  needs to be cloned or shared with the code in
>  dlls/ntdll/loader.c.
>
> I'm willing to hack up a fix for this if someone can point me
>  in the right direction.

When an app needs a certain dll windows (and wine) search according to
this:  directory of exe, current directory, system directory
(windows/system32),  windows directory (windows), and PATH env var.

What I would do if I were you is make a copy of that other needed dll
and put it in the applications exe directory.
> From what I've seen WINEDLLPATH is for internal dll.so parts of wine.

After some playing around it seems you can pass in some linux env vars
but PATH is special, and PATH is the one you would need to add your
dlls path too.  For example you can do this:

$ MYVAR="hi" wine cmd /C echo %MYVAR%

and youll get "hi" on the command line but if you try this (some
trickery to maintain your linux path involved ):

$ PATH="Z:/path/to/dll/;%PATH%:$PATH" wine cmd /C echo %PATH%

Gives me atleast (wine .9.58):
c:\windows\system32;c:\windows

Which is the exact same thing I get when I pass no env var:

$ wine cmd /C echo %PATH%

To have a temporary addition to path that is passed on the command
line it seems you could do this in windows:

cmd /V:ON /C "PATH=Z:/my/temp/path;%PATH%&& echo !PATH! && yourcommnd.exe"

However that doesn't work in wine.  Maybe because late variable
expansion (/V:ON) isn't implemented yet, I'm not sure. (I actually had
to escape the ! when trying in wine due to bash, that could have
played a role too)

--John

[Erik de Castro Lopo]

John Klehm wrote:
> When an app needs a certain dll windows (and wine) search according to
> this:  directory of exe, current directory, system directory
> (windows/system32),  windows directory (windows), and PATH env var.
>
> What I would do if I were you is make a copy of that other needed dll
> and put it in the applications exe directory.

Unfortunately, that is not a good option for my particular use
case.

My main interest in wine is for the case where I am cross
compiling from Linux to windows and want to run the cross
compiled windows executables (in particlular the test suite)
on Linux.

The particular project I want to compile like this are my
two projects libsndfile and libsamplerate, both of which have
top level source code layout of:

src       - actual library source code
    tests     - the test suite programs
    examples  - some example programs

Since these libraries uses autoconf/automake/libtool, the generated
DLL ends up as:

src/.libs/libwhatever-1.dll

and the test suite programs end up as say:

tests/test_name.exe

When doing native Linux compiles, the libtool generated wrapper
scipt correctly points to the shared object file and the test
runs correctly. I'm looking for the same functionality when
running the tests under wine.

Your proposal of just copying the DLL is not a good solution in
this case because the copied executable could get out of sync
with the one in src/.libs, invalidating the tests.
> From what I've seen WINEDLLPATH is for internal dll.so parts of wine.

I've just re-read the wine man page and it seems does support
your statement.

However, my particular use case is a particluarly interesting one.
If I and other authors of cross platform code can easily compile
and test windows binaries on Linux, you will get more wine users
of the type that can hack on wine and write great bug reports.
I also means that windows becomes increasingly irrelevant.

Cheers,
Erik

[John Klehm]

On Sun, Mar 30, 2008 at 3:37 AM, Erik de Castro Lopo
 wrote:
> Your proposal of just copying the DLL is not a good solution in
>  this case because the copied executable could get out of sync
>  with the one in src/.libs, invalidating the tests.

Well you could have a script to recopy it there but there is one more
way I thought of that you could add the path (provided you dont remove
your .wine folder very often)

wine regedit

Then edit
\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session
Manager\Environment\Path

Add your additional path dirs at the start.

That will then permanently add those to your path (will get wiped if
you reinstall your .wine folder though).  Probably could get some kind
of .reg file to do this automatically.

--John

[Erik de Castro Lopo]

John Klehm wrote:
> Well you could have a script to recopy it there but there is one more
> way I thought of that you could add the path (provided you dont remove
> your .wine folder very often)
>
> wine regedit
>
> Then edit
> \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session
> Manager\Environment\Path

Thanks for your helpful suggestions, but this still isn't a good
solution. I hope to encourage others to do cross-compiled development
of libsndfile from Linux to windows and I would like to have all of
them hack their windows registry. It just seems too fragile.

However, I notice that if instead of copying the library I make a
symlink instead, the executable runs correctly. Of the solutions
I've seen so far, this is the least fragile and most easily 
implementable solution.

Cheers,
Erik

[Steve Brown]

On Sun, 30 Mar 2008, Erik de Castro Lopo wrote:
> Your proposal of just copying the DLL is not a good solution in
> this case because the copied executable could get out of sync
> with the one in src/.libs, invalidating the tests.

You could add the copy to your makefile, so every time your .dll gets 
rebuilt, it gets automagically copied as needed.

Steve Brown
[e-mail]