Hi,
If it was such a sucker, I wouldn't have posted it :)
The innards of an autoconf macro could be unnerving, but please try it.
On Mon, Dec 7, 2015 at 2:16 AM, Gert Doering <g...@greenie.muc.de> wrote:
> Hi,
>
> On Sun, Dec 06, 2015 at 07:01:46PM -0500, Selva Nair wrote:
> > This adds a macro file with a permissive license. Its small so I don't
> > mind inlining the macro into configure.ac if that is preferred.
> > -------8<--------
>
> 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.
AC_CHECK_FUNC essentially does
char symbol();
main() { (void) symbol(); return}
That "char trick" has served us for years, but was never designed to
handle either of those two situations. Note AC_FUNC_CHECK, like most most
autoconf macros, provide only heuristics -- a symbol with that name exists
in the linked libraries, kind of..
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.
>
> 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.
>
> 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.
If you prefer I can rewrite the macro completely in terms of AC_CHECK_DECL
Selva
