[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"
#endif
:
:
#ifdef HAVE_WINSOCK2_H
# include <winsock2.h>
# undef HAVE_SELECT
# define HAVE_SELECT 1
#endif
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.
Regards,
Keith.