[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Network-related functions and configuring for MinGW
From: |
Eli Zaretskii |
Subject: |
Re: Network-related functions and configuring for MinGW |
Date: |
Sat, 07 Jan 2012 17:15:13 +0200 |
> 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.