On May 20, 2003 01:06 pm, Alexandre Julliard wrote:
winewrap is generating a wrapper script already, isn't it? So you can simply set WINEDLLPATH in there.
Well, that doesn't work. For one, WINEDLLPATH is honoured only in libs/wine/loader.c:dlopen_dll(), which is invoked only from: -- wine_dll_load_main_exe(): Try to load the .so for the main exe. -- wine_dll_load(): Load a builtin dll.
A Winelib app with a wrapper calls LoadLibrary("appname.dll"). This ends up in ./dlls/ntdll/loader.c:load_dll() which calls SearchPathA(NULL, "appname", ".dll", MAX_PATH,...) to find the DLL.
Herein lies the problem: -- SearchPathA does not know about WINEDLLPATH, it will just look for "appname.dll" which obviously does not exist (because we have "appname.dll.so"). The trace clearly shows that it will look in the right directory for "appname.dll", and it fails to find it, so it proceeds to look in the WINDOWS dir. So the path is not the problem, but rather the fact that SearchPath doesn't know to also look for .so file when searching for a .dll.
-- I've changed the wrapper to LoadLibrary("appname.dll.so"). This works a bit better in the sense that now SearchPathA finds the file. However, it fails to load because now it tries to load it as a native DLL (PE), which is not:
trace:dosfs:DOSFS_FindUnixName (/home/dimi/dev/wine/visual-mingw/bin,L"visual-mingw-wrap.dll.so") -> L"visual-mingw-wrap.dll.so" (L"VISU~Y42.SO") trace:dosfs:DOSFS_GetFullName returning /home/dimi/dev/wine/visual-mingw/bin/visual-mingw-wrap.dll.so = L"F:\DEV\WINE\VISU~YHA\BIN\VISU~Y42.SO" trace:dosfs:GetDriveTypeW (L"F:\DEV\WINE\VISU~YHA\BIN\VISU~Y42.SO") trace:file:CreateFileW returning 0x38 trace:module:PE_LoadImage loading F:\dev\wine\visual-mingw\bin\visual-mingw-wrap.dll.so warn:module:load_dll Loading of native DLL F:\dev\wine\visual-mingw\bin\visual-mingw-wrap.dll.so failed (status -1073741595). warn:module:load_dll Failed to load module 'F:\dev\wine\visual-mingw\bin\visual-mingw-wrap.dll.so'; status=-1073741595
Note: I've renamed the wrapped app "<appname>-wrap.dll" to avoid possible conflicts with app-supplied DLLs.