Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
From: "Todd West" <twest AT ee DOT washington DOT edu>
To: <cygwin AT cygwin DOT com>
Subject: anyone have implicit linkage of gcc DLLs working in Visual C?
Date: Fri, 24 Jan 2003 10:29:43 -0800
Message-ID: <KFEGLAIFLCHBEMHFJFDNOEFACAAA.twest@ee.washington.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
X-EE-Scanned: by amavisd-milter

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/