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