Help with shared library make files

Boaz Harrosh boaz at hishome.net
Wed Oct 29 08:29:55 CST 2003


I have the following setup

mfctest/Makefile - Main make file

    mfctest.exe.so - is the wrapper for an mfc gui application
    mfctest.dll.so - is the mfc gui application (as generated by the 
msvc++ wizard and than winemaker)

msvc/Makefile - make file for mfc & stuff missing from msvcrt.dll
    libmsvc.a - is all the cpp files archived by [ ar -rs 
$(ALL_OBJECT_FILES) ]
    libmsvc.so - same object files but linked with [ gcc --shared ]

Now I link mfctest.dll.so with libmsvc.a. (-l) The spec.c I prepare by 
including all the object files of the msvc project since winebuild does 
not work with libraries. It all runs fine.

Now I try to link with libmsvc.so ( exact same way as before with the -l 
option linux style, not as a DLL as usually done in wine ).
At the beginning it would not link because of undefined symbols. ( 
before with the .a option not all files get pulled in by the linker). So 
I fix the undefined s.
The spec.c file I have tried in to ways. 1) a libmsvc.spec.c for 
libmsvc.so and a small one for mfctest.dll.spec.c - and 2) A big 
mfctest.dll.spec.c that includes all objects same as above libmsvc.a . 
In both cases I had the same exact problem.

It would not run. I get a SIGSEGV. On the (gdb) back-trace it is 
directly from "dlopen" (from BUILTIN32_dlopen) it SIGs 10 functions deep 
into dlopen. The last function that makes any sense is _dl_init in 
ld-linux.so.2 from than on I get un-logical symbols that should not be 
in the init path. Including undefined s like 0x00000094 (see complete 
back-trace below) the SIGSEGV itself is reported at "dllname" which is 
not a function but an array in dll.spec.c . So we can see that the debug 
info got totally screwed up.

Big help!!! Any body got any ideas?

Do you think I need to fix the start address of libmsvc.so some how? 
What is the command line option for that?

The reason I need the libYYY.so option to work is because I have a big 
(1900 files) C++ project divided into 36 libraries. On the windows side 
it is dlls & static libs, all automatically exported by msvc++ (#define 
class class  declspec(dllexport) ). Since we do not have a good C++ way 
for pure dlls in wine (yet) and the 1900 files on one gcc link  will not 
work. ( truncated by the linker) .And I have more Applications in the 
future that use the same libraries. The .so option looks best.

One more question:
   What do the gurus say? In theory, if I have a XXX.dll.so linked Linux 
style to libYYY.so both have calls into wine. what is best method 
(XXX.dll.so is only because of the wrapper no real exports here)
    A.
        XXX.dll.so has an XXX.spec.c && libYYY.so has a YYY.spec.c of 
its own each linked to their respective .spec.c . (Note that those are 
only imports since export symbols from libYYY.so are linked against - 
Linux style).

    B. one big XXX+YYY.spec.c linked against XXX.dll.so (very very slow, 
it looks like winebuild has an o(n^2) efficiency )

    C. Both are good if no exports are made. (or exports only at the top 
lib)

Thanks for any help or pointer. Please share past experience for good or 
for worse

Free Life
Boaz

some info:
<(gdb) backtrace>
#0  0x40cb3a4d in dllname () from /home/wine/lib/wine/mfctest.dll.so
#1  0x00000094 in ?? ()
#2  0x40ffec8e in std::basic_iostream<wchar_t, std::char_traits<wchar_t> 
 >::~basic_iostream() () from /usr/lib/libstdc++.so.5
#3  0x40ffed0a in std::basic_iostream<wchar_t, std::char_traits<wchar_t> 
 >::~basic_iostream() () from /usr/lib/libstdc++.so.5
#4  0x4104dbb7 in __cxa_dyn_string_eq () from /usr/lib/libstdc++.so.5
#5  0x40feea11 in std::collate<char>::id () from /usr/lib/libstdc++.so.5
#6  0x4000aa4c in _dl_init (main_map=0x3c02eaf0, argc=4, 
argv=0xbffff454, env=0xbffff468) at dl-init.c:68
#7  0x4030a51e in _dl_open () from /lib/i686/libc.so.6
#8  0x4000a828 in _dl_catch_error (objname=0x406d28e0, 
errstring=0x406d28e4, operate=0x4030a120 <_dl_open+432>, 
args=0x406d28e8) at dl-error.c:162
#9  0x40309fcf in _dl_open () from /lib/i686/libc.so.6
#10 0x40352f21 in dlopen () from /lib/libdl.so.2
#11 0x4000a828 in _dl_catch_error (objname=0x3c0017e0, 
errstring=0x3c0017e4, operate=0x40352ef0 <dlopen+80>, args=0x406d2a68) 
at dl-error.c:162
#12 0x40353294 in dlerror () from /lib/libdl.so.2
#13 0x40352ed3 in dlopen () from /lib/libdl.so.2
#14 0x40107abc in wine_dlopen (filename=0x3c02eaa0 
"/home/wine/lib/wine/mfctest.dll.so", flag=2, error=0x406d2b08 " 
¨<@´l\016 at X,m at HÍ\a@", errorsize=256) at loader.c:577
#15 0x40107420 in dlopen_dll (name=0x406d2c2c "mfctest.dll", 
error=0x406d2b08 " ¨<@´l\016 at X,m at HÍ\a@", errorsize=256, test_only=0) at 
loader.c:156
#16 0x4010795b in wine_dll_load (filename=0x406d2c2c "mfctest.dll", 
error=0x406d2b08 " ¨<@´l\016 at X,m at HÍ\a@", errorsize=256) at loader.c:390
#17 0x4009b537 in BUILTIN32_dlopen (name=0x406d2c2c "mfctest.dll", 
handle=0x406d2c28) at ../../relay32/builtin32.c:63
#18 0x4009b94c in BUILTIN32_LoadLibraryExA (path=0x403ca710 
"C:\\WINDOWS\\SYSTEM\\mfctest.dll", flags=0, pwm=0x406d2cc4) at 
../../relay32/builtin32.c:171
#19 0x400b3c6d in load_dll (libname=0x403ca6f0 "mfctest.dll", flags=0, 
pwm=0x406d2cc4) at loader.c:1058
#20 0x400b3e34 in LdrLoadDll (path_name=0x0, flags=0, 
libname=0x406d2cfc, hModule=0x406d2cf8) at loader.c:1120
#21 0x4007e158 in LoadLibraryExA (libname=0x404b41a0 "mfctest.dll", 
hfile=0x0, flags=0) at ../../loader/module.c:655
#22 0x4007e28d in LoadLibraryA (libname=0x404b41a0 "mfctest.dll") at 
../../loader/module.c:707
#23 0x404a3147 in WinMain (hInstance=0x404b0000, hPrevInstance=0x0, 
szCmdLine=0x403908f2 "", iCmdShow=1) at mfctest.exe_wrapper.c:127
#24 0x404b40ea in __wine_exe_main () at mfctest.exe.spec.c:140
#25 0x4009fced in start_process () at ../../scheduler/process.c:455
#26 0x400a402a in call_on_thread_stack (func=0x4009fb10) at 
../../scheduler/sysdeps.c:113
</(gdb) backtrace>

<(gdb) info sharedlibrary>



More information about the wine-devel mailing list