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