load library problem

[Dimitrie O. Paun]

Hi folks,

I have flagged this before, but got no answer. Once again,
this a C++ Winelib app (one of the wxWindows samples):

[dimi(a)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(a)dimi calendar]$ export WINEDLLPATH=`pwd`
[dimi(a)dimi calendar]$ echo $WINEDLLPATH
/home/dimi/dev/wine/wxWindows/samples/calendar
[dimi(a)dimi calendar]$ wine --debugmsg +module,+loaddll calendar.exe.so  2>log
[dimi(a)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(a)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(a)dimi calendar]$ cat /tmp/wapp9rVK4g.spec
@ stdcall WinMain(ptr long ptr long) WinMain
[dimi(a)dimi calendar]$ cat /tmp/wwrpBOB32M.c
/*
 * Copyright 2000 Francois Gouget <fgouget(a)codeweavers.com> for CodeWeavers
 * Copyright 2002 Dimitrie O. Paun <dpaun(a)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;
}

-- 
Dimi.

[Vincent Béron]

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(a)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(a)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

[Dimitrie O. Paun]

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(a)dimi calendar]$ export WINEDLLPATH=/usr/local/lib/wine:`pwd`
[dimi(a)dimi calendar]$ echo $WINEDLLPATH
/usr/local/lib/wine:/home/dimi/dev/wine/wxWindows/samples/calendar
[dimi(a)dimi calendar]$ wine calendar.exe.so
Error: Could not load the application's module calendar-wrap.dll (126)
[dimi(a)dimi calendar]$ ls *.so
calendar.exe.so  calendar-wrap.dll.so

It is there, it will just not load it...

-- 
Dimi.

[Eric Pouech]

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(a)dimi calendar]$ export WINEDLLPATH=/usr/local/lib/wine:`pwd`
> [dimi(a)dimi calendar]$ echo $WINEDLLPATH
> /usr/local/lib/wine:/home/dimi/dev/wine/wxWindows/samples/calendar
> [dimi(a)dimi calendar]$ wine calendar.exe.so
> Error: Could not load the application's module calendar-wrap.dll (126)
> [dimi(a)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+

-- 
Eric Pouech

[Dimitrie O. Paun]

On September 14, 2003 02:50 am, Eric Pouech wrote:
> > [dimi(a)dimi calendar]$ export WINEDLLPATH=/usr/local/lib/wine:`pwd`
> > [dimi(a)dimi calendar]$ echo $WINEDLLPATH
> > /usr/local/lib/wine:/home/dimi/dev/wine/wxWindows/samples/calendar
> > [dimi(a)dimi calendar]$ wine calendar.exe.so
> > Error: Could not load the application's module calendar-wrap.dll (126)
> > [dimi(a)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(a)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?

-- 
Dimi.

[Eric Pouech]

Dimitrie O. Paun wrote:
> On September 14, 2003 02:50 am, Eric Pouech wrote:
> > > [dimi(a)dimi calendar]$ export WINEDLLPATH=/usr/local/lib/wine:`pwd`
> > > [dimi(a)dimi calendar]$ echo $WINEDLLPATH
> > > /usr/local/lib/wine:/home/dimi/dev/wine/wxWindows/samples/calendar
> > > [dimi(a)dimi calendar]$ wine calendar.exe.so
> > > Error: Could not load the application's module calendar-wrap.dll (126)
> > > [dimi(a)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(a)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+

-- 
Eric Pouech

[Dimitrie O. Paun]

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(a)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(a)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?)

-- 
Dimi.

[Eric Pouech]

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(a)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(a)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(a)BUILTIN32_LoadLibraryExA 
(dllname was way to short).
Alexandre, any reason for keeping this at 20 chars ?

A+

-- 
Eric Pouech

[Alexandre Julliard]

Eric Pouech <pouech-eric(a)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(a)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.

-- 
Alexandre Julliard
julliard(a)winehq.com