Subject: Re: c-ares 1.5.3 build issues/resolutions

Re: c-ares 1.5.3 build issues/resolutions

From: Yang Tse <>
Date: Mon, 29 Sep 2008 12:36:35 +0200

2008/9/29, Brad House wrote:
> >
> > > It appears as though a manual check for AR is being performed
> > > which is infact causing issues if you want to use a different AR
> > > than exists in your path, it's always overwriting it without ever
> > > checking for the variable to have already been set.
> > >
> >
> > Issues? Which ones?
> >
> Specifically, it did _NOT_ honor my custom AR, it overwrote it
> with the one it 'found' instead.
> > With mostly any version of autoconf you _really_ need the tools to be
> > available in your path. Setting the AR variable before running
> > configure should work with all autoconf versions.
> >
> In this particular case, a build script it was passing AR as
> 'ar -X 64' for IBM AIX (not sure why its not using AR_FLAGS,
> but it did uncover this issue). It ended up just using the
> found 'ar' instead. After commenting out that section, all worked
> well.

AC_PATH_TOOL and AC_CHECK_TOOL will not honor a user defined value for
the variable they check unless the user provides a 'proper' value for
the variable.

For example if you specify an AR executable which does not exist in
the user path these macros will ignore what the user has specified and
use the default one if it does exist in the user path. This must have
been your case.

You can provide arguments to the 'ar' executable in the AR variable
they will be used, you can use an absolute path or no path at all, but
what is mandatory is that the executable does exist, otherwise the
default will be used.

If you dislike how these macros work you can open an issue with the
autoconf team.

> > > I'm not sure
> > > why this check is being performed as it is one of the standard
> > > checks autoconf does already, and in a more sane manner, I'd
> > > suggest removing that block of code.
> > >
> >
> > The check is done in order to allow early detection of misconfigured
> > or incomplete build toolchain and halt the configure process. This
> > allows the user to focus on the real error instead of getting hundreds
> > of warnings which would not really help him to fix the problem on his
> > own.
> >
> I was under the assumption that configure would fail if it couldn't
> find ar. Why try to relocate the tool though? I'm pretty sure you
> could just see if $AR has been set as if it hasn't, autoconf didn't
> find it ... That should run prior to anything in your,
> afaik.

configure will not halt nor fail unless we have the check we are doing
in place. But you will get very nasty failures later when you run
'make' and the user will hopelesly wonder why is it failing.

> > Autoconf does not do this check at all, it is automagically pulled
> > from libtool which does the check, but this one does not halt the
> > configure process and after all the warnings the result is a failed
> > library build.
> >
> Autoconf definitely checks for ar...

The inter dependencies of the autotools are a real nightmare ;-)

The configure script uses AC_PROG_LIBTOOL, which seems to be an
autoconf macro. But actually it is a libtool macro. And
AC_PROG_LIBTOOL macro is the one doing the check for ar, using the
AC_CHECK_TOOL macro, but in such a way that the configure script will
end without warning on a badly configured 'AR' variable, and letting
you find out that make fails later on.

Received on 2008-09-29