Marko Lindqvist
2016-01-22 11:33:07 UTC
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?
- ML
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?
- ML