From Wine-Wiki

[edit] Introduction

Wine can load two kinds of DLLs; 'Real' and 'Fake'. 'Real' DLLs are files that come from an installation of Windows, or from an application you have installed using Wine. These are the files that end in the extension ".dll". 'Fake' DLLs are Wines internal implementation of a real DLL and end with the extension ".dll.so".

WINEDLLPATH is an environment variable used by Wine to determine where it should load its 'fake' internal DLLs from. It takes the form:

WINEDLLPATH="<directory 1>:<directory 2>:..."

i.e, A colon separated list of directories that Wine should search, in order.

Users should not need to set a value for this variable normally, because when Wine is built and installed it automatically looks for its internal DLL's where they were installed (typically under /usr/local). You should only set this variable if you want Wine to use alternate DLLs, say while testing changes to Wine itself. If you set this variable to an unsuitable value, Wine may not be able to start up correctly.

Note that this variable does not have any effect on how the Wine loader searches for the DLL's that an application needs to run.

You may be tempted to try setting this variable after seeing the error:

err:module:import_dll Library <some library>.dll (which is needed by L"<some executable>.exe") not found

When trying to run an application. This error means that when Wine started loading <some executable>, it could not find a 'real' DLL it needed. Wine uses the same rules that Windows does to find libraries used by an application, which are:

• First, try looking in the current directory.
• Next, try looking in the Windows system directory.
• Finally, try looking in the directories in the PATH environment variable.

So to correct the above error, you could try any of the following:

• Changing to the directory of <some executable> and running it again (use 'cd <directory>; wine <some executable>.exe' from a terminal, where <directory> is where the application is and <some executable>.exe is the applications name).
• Locating and copying <some library>.dll into <some executable>.exe 's directory.
• Locating and copying <some library>.dll into the c:\windows\system32 directory.
• Setting Wines PATH variable to include the directory where <some library>.dll lives.

If this does not fix the problem, try the suggestions in General Wine Troubleshooting.

WINEDLLPREFIX and all other environment variables used by Wine are documented in the manual page. For more information, try:

man wine

from a terminal prompt.

[edit] Forum and List Comments

A programmer queried the purpose and use of WINEDLLPATH jan 10 winedev:

I am wanting to direct wine to launch a specific APP.exe.so program by using WINEDLLPATH during the development of APP.exe. Unfortunately (and undocumented-ely if you know what I mean) WINEDLLPATH is superseded by /usr/lib/wine. So if /usr/lib/wine/APP.exe.so exists, WINEDLLPATH will find that one instead of the one I am trying to target.

So, if these files exist:

/usr/lib/wine/APP.exe.so

/MY_DIR/APP.exe.so

Then this command...

WINEDLLPATH=MY_DIR wine APP.exe

... will start /usr/lib/wine/APP.exe.so and not /MY_DIR/APP.exe.so.

A. julilard: It serves as an extra path where dlls can be found, but dlls from the current running installation are used first. This is to enable relocatable installs, and running from inside the build tree. Note that you can always specify the full exe path on the command line. [..] the current way is precisely what LD_LIBRARY_PATH does for relocatable installs. The loader first looks in the rpath $ORIGIN path, then in LD_LIBRARY_PATH, then in system directories. Wine does exactly the same thing. [the first search path] The first one is not /usr/lib/wine, it's wherever the Wine install has been relocated too. That's how rpath works, and it's very much intentional.

B. Klein: For DLLs at least, you should be able to rename the .dll.so to a .dll and stick it in the application's directory. I don't recall the last time I tried this, but it certainly worked (I was using a hacked ddraw.dll.so to get Diablo and Worms Armageddon playing nicely). I assume you could do something similar for EXEs. [..] 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.

A user wrote in bug 16246 that he tried to set WINEPATH with no effect:

$ export WINEPATH="C:\dir"
$ printenv | grep WINEPATH # Check if it's in the shell's environment.

WINEPATH=C:\dir

$ wine ./environment.exe # E.g.: printf("PATH=%s", getenv("PATH"));

PATH=C:\windows\system32;C:\Windows

I expect that by defining WINEPATH it would get appended to PATH. I also expect wine to search in WINEPATH folders to locate a command, e.g. "wine compiler.exe".

Answer by A. Julliard (Nov 08 winebug16246): WINEPATH is used internally to pass the PATH across Unix exec, so the feature you want is not entirely trivial to do. Still, this is a reasonable enhancement request