[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: autoconf tests and stdcall name mangling

From: Dimitrios Apostolou
Subject: Re: autoconf tests and stdcall name mangling
Date: Thu, 23 May 2013 10:55:16 +0200 (CEST)
User-agent: Alpine 2.02 (DEB 1266 2009-07-14)

On Wed, 22 May 2013, Eric Blake wrote:
On 05/22/2013 02:12 PM, Zack Weinberg wrote:
On Wed, May 22, 2013 at 1:06 PM, Nick Bowler <address@hidden> wrote:
The fundamental problem, I think, is that you really need the proper
headers included and AC_REPLACE_FUNCS does not seem to allow you to
specify the includes.  So you probably can't use this macro at all.

You can use AC_LINK_IFELSE to fully specify the test program to compile
and link, which is probably what you'll need to do here.  This may still
be tricky to get right.  Alternately, Gnulib[1] has a getaddrinfo module[2]
which may already do everything you need (although I have not used it).

I wrote the attached macro to solve a closely related problem (looking
for ntohl, not getaddrinfo; the way Winsock works, it's equivalent).
Perhaps it will be useful to you.

Going forward I think AC_*_FUNC[S] really need to grow a way to
specify headers.  Fake-declaring everything as "char foo();" has been
kinda silly for years now.

AC_CHECK_DECL ("can I compile against this function when using the right
headers") is a much better macro than AC_CHECK_FUNC ("can I link against
this symbol, and cross-my-fingers that the library actually exported it
by this name and not some other due to aliasing or stdcall or ...").
There are still a few corner cases where some platforms accidentally
declare a function but fail to export it, so both styles of probes are
still useful in practice; but generally you should try the DECL form first.

The way I'm using autoconf up to now, I first do an AC_CHECK_DECLS and right afterwards AC_REPLACE_FUNCS. For this case I'll only use AC_CHECK_DECLS, thanks everyone for helping. :-)

Maybe this warrants a patch to the autoconf manual to point this out
more emphatically; anyone want to take a stab at it?

The AC_REPLACE_FUNCS comes in really handy, so I believe it should be updated if AC_CHECK_FUNC is not the recommended way to replace non-existing functions.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]