This is the mail archive of the
cygwin@cygwin.com
mailing list for the Cygwin project.
Problems linking stdcall functions from DLL
- From: Raoul Gough <RaoulGough at yahoo dot co dot uk>
- To: cygwin at cygwin dot com
- Date: Thu, 04 Sep 2003 16:09:21 +0100
- Subject: Problems linking stdcall functions from DLL
- Cancel-lock: sha1:oBP4+noNBNXn+kIrk4KfeAAHziM=
I'm trying to link to a third party DLL that has functions with
stdcall calling convention, but *without* stdcall name decoration
(i.e. no trailing @N). Reading the ld documentation (for 2.14.90), it
looks like this should "just work", and produce warnings unless
--enable-stdcall-fixup is provided. In fact, it always produces hard
"undefined reference" errors. I've distilled this to a minimal
example:
---8<--- begin test script ---8<---------
cat >stdcall_export.c <<EOF
__attribute__((dllexport,stdcall)) int foo () { return 5; }
EOF
cat >stdcall_import.c <<EOF
__attribute__((dllimport,stdcall)) int foo ();
int main () { return foo(); }
EOF
/bin/gcc -shared -o stdcall_export.dll stdcall_export.c -Wl,--kill-at
/bin/gcc -o stdcall_import stdcall_import.c stdcall_export.dll
---8<--- end test script ---8<------------
$ ./stdcall_test.sh
/cygdrive/d/TEMP/ccklSKC0.o(.text+0x1f):stdcall_import.c:
undefined reference to `__imp__foo@0'
collect2: ld returned 1 exit status
The given code works fine if the --kill-at is omitted. So why doesn't
it resolve the reference to (dllimport) foo@0 with the corresponding
plain (dllexport) foo? Have I misunderstood how automatic stdcall
fixup works, or is this an ld bug?
ld version is 2.14.90 20030901, but problem was the same in 2.13.90
20030308.
--
Raoul Gough.
(setq dabbrev-case-fold-search nil)
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/