Problems linking stdcall functions from DLL

Problems linking stdcall functions from DLL

[Raoul Gough]

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/

Re: Problems linking stdcall functions from DLL

[Raoul Gough]

>From: "Michael Haubenwallner" michael dot haubenwallner at salomon
dot at
>To: <cygwin@cygwin.com>
>Cc: RaoulGough at yahoo dot co dot uk
>Sent: Thursday, July 01, 2004 6:04 PM
>Subject: Problems linking stdcall functions from DLL
>
> Some time ago, there was a question about linking third party dll's
> with cdecl function declarations but without the @x-decorations:
> http://www.cygwin.com/ml/cygwin/2003-09/msg00307.html
>
> Is there already a solution for this problem, as i've seen
> this test not working yet with recent binutils-20040312-1/
> gcc-3.3.1-3 on cygwin-1.5.10-3 ?
>
> Would the use of LoadLibrary()/GetProcAddress() help
> to keep the stack valid ?

I guess by "keep the stack valid" you're referring to problems calling
the function if you have declared it with the wrong calling convention
so it links properly?

I never really did find a good solution, but I've now received a
couple of emails from people experiencing the same problem, so I guess
I'll describe here what I ended up doing. I *don't* think it's a good
solution, but here it is anyway:

I was trying to use the AutoIt DLL from
http://www.hiddensoft.com/AutoIt/ and had the linking problems, etc. I
ended up having to modify the AutoIt header file so that it declared
the DLL's functions with the "wrong" attributes so that it would link
successfully (that is, "wrong" in terms of the calling convention). I
then had to set up a function pointer with the correct calling
convention attributes and call the DLL's functions via the pointer
variable. The usage looked like this (C++ code):

#include <windows.h>
#undef WINAPI
#define WINAPI   // No stdcall attribute from decls in this header
#include "AutoIt.h"
#include <cstdio>

extern "C" {
  // Correct function type for call (which ld doesn't like)
  typedef __attribute__((stdcall)) void (*RealSendType)(char *szLine);
}

int main ()
{
  // Set up function pointer with correct attributes
  RealSendType send = (RealSendType) (AUTOIT_Send);

  send ("5");
  // ...
}

This example was for the DLL function AUTOIT_Send declared in the
header as follows:

AUTOIT_API void WINAPI AUTOIT_Send(char *szLine);

WINAPI would normally be stdcall, but I do a #undef on this to remove
it. I had to modify the header to define AUTOIT_API as:

extern "C" __attribute__((dllimport))

This is not a very good solution, but I only needed to import the one
function (!). Of course you could do more or less the same thing by
using GetProcAddress.

>
> Thought just to mention an interesting site i've found about this:
> http://mywebpage.netscape.com/yongweiwu/stdcall.htm
>

Yes - looks like very relevant information. Now if somebody would just
take that information and make ld handle the problem!

-- 
Raoul Gough.


--
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/

Problems linking stdcall functions from DLL

[Michael Haubenwallner]

Some time ago, there was a question about linking third party dll's
with cdecl function declarations but without the @x-decorations:
http://www.cygwin.com/ml/cygwin/2003-09/msg00307.html

Is there already a solution for this problem, as i've seen
this test not working yet with recent binutils-20040312-1/
gcc-3.3.1-3 on cygwin-1.5.10-3 ?

Would the use of LoadLibrary()/GetProcAddress() help
to keep the stack valid ?

Thought just to mention an interesting site i've found about this:
http://mywebpage.netscape.com/yongweiwu/stdcall.htm

Thanks,
   Michael Haubenwallner
-- 
Michael Haubenwallner                    SALOMON Automation GmbH
Forschung & Entwicklung                  A-8114 Friesach bei Graz
mailto:michael.haubenwallner@salomon.at  http://www.salomon.at

--
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/