Hi, On Mon, Dec 07, 2015 at 10:31:39AM -0500, Selva Nair wrote: > > This looks interesting, but I'm not convinced that this actually *works* - > > the reason why I had to add an explicit compile test is that the standard > > configure.ac test will claim "inet_pton is not there" because the way > > the test program is built conflicts with the definitions in wstcpip.h > > > > I saw that commit in master after I wrote the macro. The commit works well, > but a macro makes it scalable. There is no reason to force define HAVE_POLL > in windows when it doesn't really have poll etc.. Not that it matters in the > current code.. > > Why AC_CHECK_FUNC doesnt detect inet_ntop or many other winsock functions > is because > (i) the function name is redefined in the header (inet_ntop is actually > InetNtopA in the librray) > (ii) declared as stdcall.
Understood :-)
> AC_CHECK_FUNC essentially does
> char symbol();
> main() { (void) symbol(); return}
... and that totally blows up here, for multiple reasons... the include
file is not there, so the redefinition does not apply and the library
indeed does not have inet_ntop() - and if you add <ws2tcpip.h>, it will
still blow up because it now redefines the prototype...
> AC_CHECK_DECL would detect inet_pton etc., because it only looks for the
> declaration in a header. The macro I submitted works almost exactly like
> AC_CHECK_DECL but defines HAVE_symbol instead of HAVE_DECL_symbol.
Not good enough. I want to be sure that the symbol is there, and that
we actually have the right libraries (so maybe a double check "the symbol
is there, but we cannot link, so fail" might be even better).
> > Which environments did you test this on? It needs to work on mingw as
> I use debian jessie, but it should work elsewhere.
>
> > shipped with ubuntu 12.04 (no inet_pton), mingw as shipped with 14.04
> > (inet_pton, *and* the definition its using conflicts with our compat/
> > libraries, so a false negative will fail later) and cygwin.
Well, the reason why I pointed out these two is that they are different
regarding header file brokenness - I'm not sure I remember the details,
but stuff that broke for me on 12.04 worked for samuli on 14.04.
It's not like unix where stuff like this just works :-)
> > It's not pretty, but it's the way it is for a reason :-)
> >
> > > + [AC_TRY_COMPILE([#include <$2>], [(void) $1;],
> >
> > This is wrong on multiple levels, actually
> >
>
> Its the AC_CHECK_DECL way of testing for a symbol. One could replace the
> COMPILE with a LINk and it will still work, though that doesn't test
> anything more than the copile in this case.
>
> Note that its not (void) $1(), its just (void) $1.
So it's building a test program that does this?
#include <ws2tcpip.h>
main()
{
(void) inet_ntop;
}
... which shouldn't compile at all...?
> If you prefer I can rewrite the macro completely in terms of AC_CHECK_DECL
Convince me that it improves things :-)
Right now, it makes stuff *less* clear to the autoconf-non-enlightened,
like me. I do understand the check that we have no, I do not understand
your stuff (quite obvious from my dumb questions)...
(I agree that we shouldn't force-define HAVE_POLL if we don't use that
stuff on windows at all - so I'm happy to see such things just go out...)
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025 g...@net.informatik.tu-muenchen.de
signature.asc
Description: PGP signature
