Re: Network-related functions and configuring for MinGW

[Eli Zaretskii]

> Date: Sat, 07 Jan 2012 07:56:49 -0700
> From: Eric Blake <address@hidden>
> CC: address@hidden
> 
> Have you considered priming a config.site cache to work around these
> problems by default?

I might do that, but I thought reporting the problems here will
contribute to their solution at some future time, as opposed to solve
only my own problem (which I already solved, see below).

> Also, patching autoconf won't help you right away - it may take several
> years before the changes percolate through to the affected packages.
> While that's not an argument against fixing things, I'm just trying to
> set expectations, and to point out that you may want to also report
> these issues to affected packages in parallel.

I solved these problems by specifying CPPFLAGS or DEFINES at configure
time.  So I don't need to wait till the solutions percolate through
the channels.  But I thought that other users might be saved from the
need to investigate these issues in the future, if I report them.

> > This happens because the configure script assumes the prototypes of
> > these functions are in certain headers, but winsock2.h on Windows is
> > not included in the list of those headers.  And that's where those
> > prototypes are found on Windows.  However, the only Windows-specific
> > header searched by configure is io.h.
> 
> Blindly testing for winsock2.h is wrong on Cygwin.

Well, it's easy to have a MinGW-specific test in the test program used
by Autoconf.

> Gnulib has much better support for detecting network-related
> functions, using the correct headers, and where needed, adding the
> appropriate windows libraries into the link line.

Using the gnulib replacements causes compilation warnings (due to use
of `restrict', AFAICS, which the MinGW headers don't).  In addition, I
prefer using the original Windows prototypes due to all kinds of
subtle issues with WSAPI etc.  Why replace prototype declarations that
already exist?

> > There's another group of network-related functions that needs
> > _WIN32_WINNT to be defined to 0x0501, otherwise the prototypes will
> > not be seen by the compiler.  This group of functions includes
> > getaddrinfo, getnameinfo, and freeaddrinfo.  Because the configure
> > script does not define this macro in the test programs it runs, it
> > incorrectly concludes that these functions are missing, which leads to
> > warnings and errors during the build.
> > 
> > Is it possible to update the Autoconf tests so as to eliminate these
> > problems?
> 
> Which macros in particular?

Those that test for the 3 functions I mentioned above need
_WIN32_WINNT.  Other network-related functions need to include the
winsock header.

> For example, autoconf does NOT have any macros for getaddrinfo.  At
> this point, I think this is more a case of autoconf not providing
> any higher-level macros for the situation, so many packages are
> (poorly) re-inventing the checks by building on lower-level autoconf
> primitives, rather than reusing existing higher-level macros from
> places like gnulib.

Possibly, I don't know enough about Autoconf to judge.

> Adding new macros to autoconf won't help things until those packages use
> the new macros.

Again, I thought I'd report this to save others from the same
nuisance.

> And at this point, since gnulib's macros are better,

Sorry, I don't think they are better.  And not every package even uses
gnulib.

> That is, I'm not opposed to helping, but I'm not sure what help we can
> offer from autoconf other than documenting that functions like
> getaddrinfo are complex enough to warrant using gnulib for proper detection.

Whatever the path that is taken, I hope the result will be that the
affected packages will configure correctly and build without warnings
or errors.  I generally watch the reports of the configure script very
closely, and seeing it misreport functions as missing, when I know for
a fact that they exist, is not reassuring, to say the least.

Thanks.