> Date: Sat, 07 Jan 2012 07:56:49 -0700 > From: Eric Blake <ebl...@redhat.com> > CC: bug-autoconf@gnu.org > > 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.
