Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/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
Message-ID: <014e01c461f8$de26e090$0200a8c0@albert>
From: "Raoul Gough" <RaoulGough AT yahoo DOT co DOT uk>
To: <cygwin AT cygwin DOT com>
References: <40E44433 DOT 4090204 AT salomon DOT at>
Subject: Re: Problems linking stdcall functions from DLL
Date: Sun, 4 Jul 2004 19:58:17 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

>From: "Michael Haubenwallner" michael dot haubenwallner at salomon
dot at
>To: <cygwin AT cygwin DOT 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/