[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Checking for PASCAL decl funcs/libs

From: Keith MARSHALL
Subject: Re: Checking for PASCAL decl funcs/libs
Date: Mon, 23 Jan 2006 15:05:20 +0000

Dizzy wrote:
> I am trying to tune one autoconf at a project I work on to be
> able to use it when cross-compiling with mingw on a linux box
> for a win32 target.  I have problems using AC_CHECK_LIB and
> AC_CHECK_FUNC for libraries and functions. 
> From what I have debugged so far the problem seems to be that
> the functions in the mingw provided "win32 runtime" are declared
> with "PASCAL" declaration style and as such they mangle differently
> for linking than the C ones.  So AC_CHECK_LIB and AC_CHECK_FUNC both
> do dummy C declarations for the functions looked up and the program
> obviously doesnt link. I had to use AC_LINK_IFELSE with my own source
> to have the tested source include a proper header (that does the
> proper PASCAL declarations) instead of generating the dummy C 
> declaration like in:

This has little to do with PASCAL, and *everything* to do with the
distinction that Win32 makes between `__cdecl' and `__stdcall' function
calling protocols.  (In fact, IIRC `PASCAL' is a deprecated form for
declaring a `__stdcall' function.

The problem is that there is no such distinction in the *nix world,
where all functions are effectively `__cdecl'.  Thus AC_CHECK_FUNC and
AC_CHECK_LIB always test on the basis of generated function prototypes
conforming to the `__cdecl' protocol, and so fail to link against the
`__stdcall' decorated symbol name, present in the library, when you
test for the presence of a `__stdcall' function.

> I whould [sic] need first to check for the 
> headers (if the enviroment provides something like "winsock2.h")
> then the source I use to check for the function should do 
> #ifdef HAVE_WINSOCK2_H
> # include <winsock2.h>
> #endif
> ...

If you intend your application to be cross-platform, then you should
*always* do this, at the point in your actual source code, where you
indend to use the functions you are checking for;  therefore, the
AC_CHECK_HEADER would be required anyway.  Once you've determined
that such Win32 headers are present, and usable, then you can usually
safely assume that any functions they declare *are* available, even
if AC_CHECK_FUNC or AC_CHECK_LIB fails to find them.  So, in your
application code, you could have something like:

  #ifdef HAVE_CONFIG_H
  # include "config.h"
  #ifdef HAVE_WINSOCK2_H
  # include <winsock2.h>
  # undef HAVE_SELECT
  # define HAVE_SELECT 1

and simply ignore configure's define for HAVE_SELECT.

To use AC_CHECK_LIB, to check for the availability of Win32 libraries,
try to call a `__cdecl' function which is representative of the library.
Again, once you've verified the presence of a particular Win32 library,
you can usually make assumptions about provided functions, and avoid
specifically checking for `__stdcall' functions.

If you *do* insist on explicitly checking for `__stdcall' functions,
then the standard AC_CHECK_FUNC and AC_CHECK_LIB will not serve; there
would seem to be no alternative but to deploy non-standard macros, to
fulfill the purpose.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]