Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , 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" To: 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: >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 #undef WINAPI #define WINAPI // No stdcall attribute from decls in this header #include "AutoIt.h" #include 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/