Hi folks,
I have flagged this before, but got no answer. Once again, this a C++ Winelib app (one of the wxWindows samples):
[dimi@dimi calendar]$ ls calendar* calendar calendar_calendar.o calendar.cpp calendar.exe.so calendar.o calendar.rc calendar-wrap.dll.so calendar.bkl calendar_calendar_rc.o calendar.dsp calendarM5.xml calendar.pro calendar_resources.o [dimi@dimi calendar]$ export WINEDLLPATH=`pwd` [dimi@dimi calendar]$ echo $WINEDLLPATH /home/dimi/dev/wine/wxWindows/samples/calendar [dimi@dimi calendar]$ wine --debugmsg +module,+loaddll calendar.exe.so 2>log [dimi@dimi calendar]$ tail log trace:module:GetModuleFileNameW L"F:\dev\wine\wxWindows\samples\calendar\calendar.exe" trace:module:GetModuleFileNameW L"F:\dev\wine\wxWindows\samples\calendar\calendar.exe" trace:module:MODULE_GetLoadOrder looking for C:\WINDOWS\SYSTEM\calendar-wrap.dll trace:module:GetModuleFileNameW L"F:\dev\wine\wxWindows\samples\calendar\calendar.exe" trace:module:open_app_key searching 'calendar-wrap' in AppDefaults\calendar.exe\DllOverrides trace:module:MODULE_GetLoadOrder got standard wildcard "b,n" for "calendar-wrap.dll" trace:module:load_dll Trying built-in 'C:\WINDOWS\SYSTEM\calendar-wrap.dll' trace:module:load_dll Trying native dll 'C:\WINDOWS\SYSTEM\calendar-wrap.dll' warn:module:load_dll Failed to load module 'C:\WINDOWS\SYSTEM\calendar-wrap.dll'; status=c000000f Error: Could not load the application's module calendar-wrap.dll (126)
The piece of code that fails is from the automatically generated wrapper[1]. Here is the part that fails: LoadLibrary("calendar-wrap.dll");
I have the WINEDLLPATH set, what gives? Alexandre, I can't really track this easily back, but I have a gut feeling it got triggered by one of the reorganizations that you did around the loader...
[1] That is how the app was linked: [dimi@dimi calendar]$ winewrap -v -k -mgui -C -o calendar.exe calendar_calendar.o calendar_calendar_rc.o -L../../lib -lwx_msw-2.5 -lwxexpat -lz -lrpcrt4 -loleaut32 -lole32 -lwine_uuid -lwinspool -lwinmm -lshell32 -lcomctl32 -lcomdlg32 -lctl3d32 -ladvapi32 -lwsock32 -lgdi32 -lpng -ljpeg -ltiff -lcomdlg32 -ladvapi32 -lshell32 Creating file /tmp/wapp9rVK4g.spec winebuild -o /tmp/wapp9rVK4g.spec.c -F calendar-wrap.dll --spec /tmp/wapp9rVK4g.spec -L/usr/local/lib/wine -L../../lib -lrpcrt4 -loleaut32 -lole32 -lwinspool -lwinmm -lshell32 -lcomctl32 -lcomdlg32 -lctl3d32 -ladvapi32 -lwsock32 -lgdi32 -lcomdlg32 -ladvapi32 -lshell32 -lgdi32 -luser32 -lkernel32 calendar_calendar.o calendar_calendar_rc.o ../../lib/libwx_msw-2.5.a ../../lib/libwxexpat.a /usr/lib/libz.a /usr/local/lib/libwine_uuid.a ../../lib/libpng.a ../../lib/libjpeg.a ../../lib/libtiff.a gcc -fPIC -o /tmp/wapp9rVK4g.spec.o -c /tmp/wapp9rVK4g.spec.c g++ -shared -Wl,-Bsymbolic,-z,defs -lwine -lm -L/usr/local/lib/wine -L../../lib -o calendar-wrap.dll.so /tmp/wapp9rVK4g.spec.o calendar_calendar.o ../../lib/libwx_msw-2.5.a ../../lib/libwxexpat.a /usr/lib/libz.a /usr/local/lib/libwine_uuid.a ../../lib/libpng.a ../../lib/libjpeg.a ../../lib/libtiff.a Creating file /tmp/wwrpBOB32M.c gcc -fPIC -I/usr/local/include/wine/windows -o /tmp/wwrpBOB32M.o -c /tmp/wwrpBOB32M.c winebuild -o /tmp/wwrpBOB32M.spec.c --exe calendar.exe -mgui /tmp/wwrpBOB32M.o -L/usr/local/lib/wine -L../../lib -lrpcrt4 -loleaut32 -lole32 -lwinspool -lwinmm -lshell32 -lcomctl32 -lcomdlg32 -lctl3d32 -ladvapi32 -lwsock32 -lgdi32 -lcomdlg32 -ladvapi32 -lshell32 -lgdi32 -luser32 -lkernel32 gcc -fPIC -o /tmp/wwrpBOB32M.spec.o -c /tmp/wwrpBOB32M.spec.c g++ -shared -Wl,-Bsymbolic,-z,defs -lwine -ldl -o calendar.exe.so /tmp/wwrpBOB32M.spec.o /tmp/wwrpBOB32M.o Creating file calendar
[dimi@dimi calendar]$ cat /tmp/wapp9rVK4g.spec @ stdcall WinMain(ptr long ptr long) WinMain [dimi@dimi calendar]$ cat /tmp/wwrpBOB32M.c /* * Copyright 2000 Francois Gouget fgouget@codeweavers.com for CodeWeavers * Copyright 2002 Dimitrie O. Paun dpaun@rogers.com */
#include <stdio.h> #include <windows.h>
/* * Describe the wrapped application */
/* The app name */ #define APPNAME "calendar" /** * This is either 0 for a console based application or * 1 for a regular windows application. */ #define GUIEXE 1
/** * This is the name of the library containing the application, * e.g. 'hello-wrap.dll' if the application is called 'hello.exe'. */ static char* appName = APPNAME "-wrap.dll";
/** * This is the name of the application's Windows module. If left NULL * then appName is used. */ static char* appModule = NULL;
/** * This is the application's entry point. This is usually 'WinMain' for a * gui app and 'main' for a console application. */ #if GUIEXE static char* appInit = "WinMain"; #else static char* appInit = "main"; #endif
/** * This is either non-NULL for MFC-based applications and is the name of the * MFC's module. This is the module in which we will take the 'WinMain' * function. */ static char* mfcModule = NULL;
void error(const char *format, ...) { va_list ap; char msg[4096];
va_start(ap, format); vsnprintf(msg, sizeof(msg), format, ap); fprintf(stderr, "Error: %s\n", msg); /*MessageBox(NULL, msg, "Error", MB_OK);*/ va_end(ap); exit(1); }
#if GUIEXE typedef int WINAPI (*WinMainFunc)(HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine, int iCmdShow); #else typedef int WINAPI (*MainFunc)(int argc, char** argv, char** envp); #endif
#if GUIEXE int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine, int iCmdShow) #else int WINAPI main(int argc, char** argv, char** envp) #endif { HINSTANCE hApp = 0, hMFC = 0, hMain = 0; void* appMain; int retcode;
/* Then if this application is MFC based, load the MFC module */ if (mfcModule) { hMFC = LoadLibrary(mfcModule); if (!hMFC) error("Could not load the MFC module %s (%d)", mfcModule, GetLastError()); /* For MFC apps, WinMain is in the MFC library */ hMain = hMFC; }
/* Load the application's module */ if (!appModule) appModule = appName; hApp = LoadLibrary(appModule); if (!hApp) error("Could not load the application's module %s (%d)", appModule, GetLastError()); if (!hMain) hMain = hApp;
/* Get the address of the application's entry point */ appMain = GetProcAddress(hMain, appInit); if (!appMain) error("Could not get the address of %s (%d)", appInit, GetLastError());
/* And finally invoke the application's entry point */ #if GUIEXE retcode = (*((WinMainFunc)appMain))(hApp, hPrevInstance, szCmdLine, iCmdShow); #else retcode = (*((MainFunc)appMain))(argc, argv, envp); #endif
/* Cleanup and done */ FreeLibrary(hApp); FreeLibrary(hMFC);
return retcode; }
Le ven 12/09/2003 à 03:13, Dimitrie O. Paun a écrit :
Hi folks,
I have flagged this before, but got no answer. Once again, this a C++ Winelib app (one of the wxWindows samples):
[dimi@dimi calendar]$ ls calendar* calendar calendar_calendar.o calendar.cpp calendar.exe.so calendar.o calendar.rc calendar-wrap.dll.so calendar.bkl calendar_calendar_rc.o calendar.dsp calendarM5.xml calendar.pro calendar_resources.o [dimi@dimi calendar]$ export WINEDLLPATH=`pwd`
Try setting WINEDLLPATH="/usr/local/lib/wine:`pwd`" and see if it goes further.
I think it's been triggered buy Juraj lately, with a nice backtrace to a pthread function called by somewhere in dlerror() while trying to load ntdll.dll from the first dllpath (ie, the first one in WINEDLLPATH).
Vincent
On September 12, 2003 06:47 am, Vincent Béron wrote:
Try setting WINEDLLPATH="/usr/local/lib/wine:`pwd`" and see if it goes further.
No, I got the same problem:
[dimi@dimi calendar]$ export WINEDLLPATH=/usr/local/lib/wine:`pwd` [dimi@dimi calendar]$ echo $WINEDLLPATH /usr/local/lib/wine:/home/dimi/dev/wine/wxWindows/samples/calendar [dimi@dimi calendar]$ wine calendar.exe.so Error: Could not load the application's module calendar-wrap.dll (126) [dimi@dimi calendar]$ ls *.so calendar.exe.so calendar-wrap.dll.so
It is there, it will just not load it...
Dimitrie O. Paun wrote:
On September 12, 2003 06:47 am, Vincent Béron wrote:
Try setting WINEDLLPATH="/usr/local/lib/wine:`pwd`" and see if it goes further.
No, I got the same problem:
[dimi@dimi calendar]$ export WINEDLLPATH=/usr/local/lib/wine:`pwd` [dimi@dimi calendar]$ echo $WINEDLLPATH /usr/local/lib/wine:/home/dimi/dev/wine/wxWindows/samples/calendar [dimi@dimi calendar]$ wine calendar.exe.so Error: Could not load the application's module calendar-wrap.dll (126) [dimi@dimi calendar]$ ls *.so calendar.exe.so calendar-wrap.dll.so
It is there, it will just not load it...
WINEDLLPATH is always (re)set by the wine(wrapper) script Does this help ?
Index: winewrapper =================================================================== RCS file: /home/cvs/cvsroot/wine/wine/tools/winewrapper,v retrieving revision 1.6 diff -u -u -r1.6 winewrapper --- winewrapper 1 May 2003 03:16:21 -0000 1.6 +++ winewrapper 14 Sep 2003 06:48:27 -0000 @@ -68,7 +68,12 @@ else LD_LIBRARY_PATH="$topdir/dlls:$topdir/libs" fi -WINEDLLPATH="$topdir/dlls:$topdir/programs" +if [ -n "$WINEDLLPATH" ] +then + WINEDLLPATH="$topdir/dlls:$topdir/programs:$WINEDLLPATH" +else + WINEDLLPATH="$topdir/dlls:$topdir/programs" +fi WINESERVER="$topdir/server/wineserver" WINELOADER="$topdir/miscemu/wine" export LD_LIBRARY_PATH WINEDLLPATH WINESERVER WINELOADER
A+
On September 14, 2003 02:50 am, Eric Pouech wrote:
[dimi@dimi calendar]$ export WINEDLLPATH=/usr/local/lib/wine:`pwd` [dimi@dimi calendar]$ echo $WINEDLLPATH /usr/local/lib/wine:/home/dimi/dev/wine/wxWindows/samples/calendar [dimi@dimi calendar]$ wine calendar.exe.so Error: Could not load the application's module calendar-wrap.dll (126) [dimi@dimi calendar]$ ls *.so calendar.exe.so calendar-wrap.dll.so
It is there, it will just not load it...
WINEDLLPATH is always (re)set by the wine(wrapper) script Does this help ?
Well, it doesn't as I don't use the winewrapper script at all. This is a sample application that comes with wxWindows, and is compiled as a Winelib app via winegcc.
But regardless, look how it is being invoked:
[dimi@dimi calendar]$ wine calendar.exe.so
as you can see, there are no scripts in the middle. Just wine and the binary. Check out the initial relay trace that I've posted at the beginning of the thread:
http://www.winehq.org/hypermail/wine-devel/2003/09/0496.html
Any idea what's going on here?
Dimitrie O. Paun wrote:
On September 14, 2003 02:50 am, Eric Pouech wrote:
[dimi@dimi calendar]$ export WINEDLLPATH=/usr/local/lib/wine:`pwd` [dimi@dimi calendar]$ echo $WINEDLLPATH /usr/local/lib/wine:/home/dimi/dev/wine/wxWindows/samples/calendar [dimi@dimi calendar]$ wine calendar.exe.so Error: Could not load the application's module calendar-wrap.dll (126) [dimi@dimi calendar]$ ls *.so calendar.exe.so calendar-wrap.dll.so
It is there, it will just not load it...
WINEDLLPATH is always (re)set by the wine(wrapper) script Does this help ?
Well, it doesn't as I don't use the winewrapper script at all. This is a sample application that comes with wxWindows, and is compiled as a Winelib app via winegcc.
But regardless, look how it is being invoked:
[dimi@dimi calendar]$ wine calendar.exe.so
as you can see, there are no scripts in the middle. Just wine and the binary. Check out the initial relay trace that I've posted at the beginning of the thread:
http://www.winehq.org/hypermail/wine-devel/2003/09/0496.html
Any idea what's going on here?
Another issue could be the (.so) dependencies on wine-calendar.dll.so which cannot be resolved.
A+
On September 14, 2003 03:07 am, Eric Pouech wrote:
Another issue could be the (.so) dependencies on wine-calendar.dll.so which cannot be resolved.
I think you mean calendar-wrap.dll.so. Hmm, that would be very odd. Do you see any problem with these:
[dimi@dimi calendar]$ ldd calendar.exe.so libwine.so => /usr/local/lib/libwine.so (0x40029000) libdl.so.2 => /lib/libdl.so.2 (0x40040000) libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x40044000) libm.so.6 => /lib/tls/libm.so.6 (0x400f8000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4011a000) libc.so.6 => /lib/tls/libc.so.6 (0x42000000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) [dimi@dimi calendar]$ ldd calendar-wrap.dll.so libwine.so => /usr/local/lib/libwine.so (0x402f5000) libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x4030c000) libm.so.6 => /lib/tls/libm.so.6 (0x403bf000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x403e2000) libc.so.6 => /lib/tls/libc.so.6 (0x42000000) libdl.so.2 => /lib/libdl.so.2 (0x403ea000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
It seems to me calendar-wrap.dll.so has the same dependencies as calendar.exe.so (in a bit different order, does it matter?)
Dimitrie O. Paun wrote:
On September 14, 2003 03:07 am, Eric Pouech wrote:
Another issue could be the (.so) dependencies on wine-calendar.dll.so which cannot be resolved.
I think you mean calendar-wrap.dll.so. Hmm, that would be very odd. Do you see any problem with these:
[dimi@dimi calendar]$ ldd calendar.exe.so libwine.so => /usr/local/lib/libwine.so (0x40029000) libdl.so.2 => /lib/libdl.so.2 (0x40040000) libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x40044000) libm.so.6 => /lib/tls/libm.so.6 (0x400f8000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4011a000) libc.so.6 => /lib/tls/libc.so.6 (0x42000000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) [dimi@dimi calendar]$ ldd calendar-wrap.dll.so libwine.so => /usr/local/lib/libwine.so (0x402f5000) libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x4030c000) libm.so.6 => /lib/tls/libm.so.6 (0x403bf000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x403e2000) libc.so.6 => /lib/tls/libc.so.6 (0x42000000) libdl.so.2 => /lib/libdl.so.2 (0x403ea000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
It seems to me calendar-wrap.dll.so has the same dependencies as calendar.exe.so (in a bit different order, does it matter?)
after some more exchanges with Dimi, it turned out that this was caused by a too short buffer in relay32/builtin32.c@BUILTIN32_LoadLibraryExA (dllname was way to short). Alexandre, any reason for keeping this at 20 chars ?
A+
Eric Pouech pouech-eric@wanadoo.fr writes:
after some more exchanges with Dimi, it turned out that this was caused by a too short buffer in relay32/builtin32.c@BUILTIN32_LoadLibraryExA (dllname was way to short). Alexandre, any reason for keeping this at 20 chars ?
No, there's no reason, that's a leftover from the Win16 version. It should probably be MAX_PATH or something like that.