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. _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
