autoconf
[Top][All Lists]
Advanced

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

Re: Conflict between standard headers and winsock(2).h


From: Peter Rosin
Subject: Re: Conflict between standard headers and winsock(2).h
Date: Tue, 21 Aug 2018 17:00:07 +0200
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

On 2016-01-22 12:33, Marko Lindqvist wrote:
> When building a project on MSYS2 environment, my configure fails to
> find out that the winsock2.h is available there.
>  Simple AC_CHECK_HEADER() for winsock2.h fails, and so would many
> standard macros if it was to be included.  The reason for that failure
> is that while the standard headers (unistd.h in my case, though itself
> included from the very first stdio.h include already) are protected
> against conflicts with winsock stuff, they can do that only if they
> are included after winsock2.h.
> 
>  With a local macro I've confirmed that prepending '#include
> <winsock2.h>" to $ac_includes_default, when possible, does fix this.
> At least all the macros I were interested about were behaving
> correctly after that. Of course I have to call that macro of mine as
> early as possible so that it won't invalidate any tests that have been
> run on the assumption that <winsock2.h> is not included in the
> beginning.
> 
>  Is there more proper way to achieve this than directly prepending
> $ac_includes_default, or is there any plans for such support?

I have used something like the following for this situation:

AC_CHECK_HEADERS([ \
        foo1.h \
        foo2.h \
        etc.h \
        windows.h \
        winsock2.h \
        winsock.h \
        ws2tcpip.h \
        shlobj.h \
        wspiapi.h \
        ], [], [], [
AC_INCLUDES_DEFAULT
#define WIN32_LEAN_AND_MEAN
#ifdef HAVE_WINDOWS_H
#include <windows.h>
#endif
#ifdef HAVE_WINSOCK2_H
#include <winsock2.h>
#endif
#ifdef HAVE_WINSOCK_H
#include <winsock.h>
#endif
])

In practice, I'm sure you can skip winsock.h and I'm not sure this
solves your problem, but you might be able to adapt it...

Cheers,
Peter



reply via email to

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