autoconf
[Top][All Lists]
Advanced

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

Re: Why configure failed to search libws2_32.a in MinGW+MSYS ?


From: Keith Marshall
Subject: Re: Why configure failed to search libws2_32.a in MinGW+MSYS ?
Date: Fri, 27 Dec 2013 20:47:50 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

On 27/12/13 08:58, Guo Leaveye wrote:
> Given a short WinSock program source _testlib.c_ here:
> 
>     /* testlib.c */
>     #include <stdio.h>
>     #include <windows.h>
>     #include <winsock2.h>

I'm astonished that this works!  If you include winsock2.h, then you
either should *not* include windows.h, or you should ensure that you
include winsock2.h first.  (Microsoft document the former option, but
not the latter; their documented alternative, if you need to include
both headers, is to define WIN32_LEAN_AND_MEAN, before you include either).

>     int main( void ) {
>         printf( "%d\n", WSAGetLastError() );
>         return 0;
>     }
> 
> Directly compile of the testlib.c goes just fine. So I think the MSYS+MinGW 
> works well. To simulate the autotools' progress, I tried that compile to 
> testlib.o and then link the execution. It works too.
> 
>     $ gcc -c -o testlib.o testlib.c && gcc -o out testlib.o -lws2_32 && ls -l 
> out*
>     -rwxr-xr-x 1 Administrator Administrators 48899 Dec 27 16:27 out.exe

See above; I'm surprised that it works, as you've shown your example,
but with correct usage, there should be no problem.

> After that, I turn it into autotools:
> 
>     # configure.ac
>     . . .
>     AC_PROG_CC
>     AC_CHECK_LIB([ws2_32], [WSAGetLastError])
>     AC_CHECK_LIB([libws2_32], [WSAGetLastError])

This simply *cannot* work as you hope.  See, WSAGetLastError() is a
__stdcall function, which requires the appropriate headers to have been
included at compile time, to get the correct __stdcall qualification of
the symbol references for the linker.  IIRC, AC_CHECK_LIB deliberately
omits the headers, providing a dummy prototype instead; this is only
suitable for __cdecl functions, so failure to detect libws2_32.a must
always be the expected outcome here.

Normal practice for Windows ports is to simply assume that the requisite
libraries are always present.  If you feel that you really need to test
for it, either just check for availability of the header, and assume
that is always accompanied by the requisite library, or you must write a
custom AC_LINK_IFELSE test; AC_CHECK_LIB will not be of much use to you
here.

-- 
Regards,
Keith.



reply via email to

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