Re: handling of missing AR

[Ralf Wildenhues]

Hi Tim,

* Tim Mooney wrote on Wed, Mar 29, 2006 at 10:02:31PM CEST:
> In regard to: Re: handling of missing AR, Ralf Wildenhues said (at 9:33pm...:
> >* Brian Gough wrote on Wed, Mar 29, 2006 at 09:11:54PM CEST:
> >>
> >>I've had a libtool-related problem reported with a test release of GNU
> >>GSL on a Solaris system with gcc & Sun ld, but missing 'ar'.
> >
> >Erm.  The user did not have /usr/ccs/bin in $PATH?
> >I've never heard about a Solaris where ar was not installed.
> 
> Considering Solaris 10 does away with archive libraries, it wouldn't
> be a big surprise if some future release doesn't include "ar" by default
> (though it probably has to be available as an install option for standards 
> conformance).

Yes, maybe, but this is a developer system.  It seems to me like an
installation error that ar is not present.

> On my Solaris 10 system, ar is installed in /usr/ccs/bin/ar
> (from SUNWbtool) and /usr/xpg4/bin/ar (from SUNWxcu4).

Oh, I did not mean to imply that /usr/ccs/bin/ar is the only, or
preferred one; we certainly should append /usr/ccs/bin here.

> >>The question was asked "Why doesn't configure stop with an error when
> >>it finds ar is missing?"  I didn't have a good answer to that.  For
> >>the average user the final error message is a hard to decipher.
> >
> >Well yes, but sometimes ar is not needed, for example it /may/ not be
> >needed when --disable-static is given.
> 
> But if --disable-static is *not* given, shouldn't it be required?  

Hmm.  It's also required when convenience archives are used, whether or
not --disable-static was given; we can't know that at configure time.

> Shouldn't libtool's portion of configure fail in that case?

I'm not really in favor of adding lots of failure points to macros.
Sure, there are some hideous cases (missing `file' on Cygwin is, umm,
leads to rather unobvious issues, for example), but this one isn't:
the build will obviously fail the first time the missing tool is used.

Here's a bit of hand-waving why I'm not too fond of hard failures:
Completely orthogonal to this issue at hand, there was last week a bug
report on one of the Autoconf lists: all but the first-invoked of the
macros AC_PROG_CC, AC_PROG_CXX, AC_PROG_F77 would not cause a configure
error if the macro won't find a suitable compiler.  That lead to weird
followup decisions of the configure script.  Looking into a fix, let's
remember that Libtool-1.5.x (but not CVS HEAD) unfortunately has that
bug that it unconditionally calls all of the above, even if the
respective languages are not used at all.  So users of packages that
don't come anywhere near Fortran would need to install a Fortran
compiler to be able to successfully run `configure'.  Tell that to
someone with a system where there is no such thing as a Fortran
compiler.

See my point?  Hard failure isn't always the best thing to do, if you
are writing a macro to be used in other packages.  It may be different
if you are writing configure.ac: you know that your package will need
this and that, and you want early failure.  With macros, I usually would
prefer at least an optional RUN-IF-FAIL argument that could be executed
instead.  Thing with AC_PROG_LIBTOOL is that it's huge, and there is not
just one well-defined point of failure.  :-/

Hope this helps a bit.

Cheers,
Ralf