Mail Archives: cygwin/2003/01/24/13:29:59
I'm experimenting with using Cygwin and gcc -shared to build Windows DLLs
which are called by code compiled by VC6.0 SP5 or the Intel C 7.0 plug-in
for VC. I've using some very small stubs of test code and DLLs extracted
from Atlas 3.4.1. Implicitly linked calls go down fine at compile and link
time with .libs generated by gcc, but seg fault at run time. Explicit DLL
linkage works fine (e.g. LoadLibrary() and GetProcAddress()); I can even
make successful calls across C++ ABIs.
If I look at the disassembly for implicit linkage what happens is that the
caller code correctly jmps to the DLL's export routing and is set to jmp to
the correct address inside the DLL. However, the second jmp goes bad and
lands in the middle of nowhere. E.g., it's ready to jmp to clapack_zgesv at
0x001ee170 but instead jmps to 0x0000a190 and blows up.
Anybody have any ideas why things are going wrong here? Is there a gcc
incantation which works for implicit linkage? Is it even supposed to work
with VC, or is gcc -shared only reliable for producing DLLs to be linked
with gcc?
The gcc call I've tested most thoroughly is
gcc -mno-cygwin -shared -o ${dllname} --export-all ${objects}
${mingw_libs_needed_for_linkage} -Wl,--out-implib=${import_lib_name}
which successfully produces Cygwin free DLLs (no linkage to cygwin1.dll)
with both gcc 3.2 and gcc 2.95. I've also exprimented with various forms of
the full syntax, which is apparently
gcc -mno-cygwin -shared -o ${dllname} ${deffile} \
-Wl,--out-implib=${libname} \
-Wl,--enable-auto-import \
-Wl,--whole-archive ${gotta_have_libs} \
-Wl,--no-whole-archive ${subset_libs}
and gotten similar results. Same thing with using -Wl,--export-all-symbols
instead of a .def.
Todd
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -