Re: libs.am/AR = ar

[Andy Helten]

Alexandre Duret-Lutz wrote:

> > > > "Ralf" == Ralf Corsepius <address@hidden> writes:
>
> Ralf> Simple question:
> Ralf> Why is AR = ar hard-coded into libs.am?
>
> [...]
>
> Ralf> This causes cross-compiled packages which apply 
> Ralf> AC_CHECK_TOOL(AR,ar)
> Ralf> to silently use "ar" instead of the desired @address@hidden 
>
> Our of curiosity, does it break something?
>
> (I'm still waiting for someone to confirm or negate this statement:
> http://mail.gnu.org/pipermail/bug-automake/2001-November/000372.html)

I'm the one that originally posted this problem, and the answer to "does 
it break something" is yes.  I responded long ago to this with the 
following explanation:

Stock Solaris doesn't provide an 'ar' executable within most user's normal 
path, for example, on my system it is in /usr/ccs/bin.  So of course, 'AR=ar' 
results in make failures because 'ar' is not found.

In some systems used only for cross-compiling (embedded development for 
example), it is not uncommon to have _no_ native compiler tools 
installed.  In these cases compilation or configure comes to a halt 
because no ar is found.  Does it cause problems using ar when it is 
found?  Probably not, but I can't say for sure.

> Ralf> Not worth mentioning toolchains where the "archiver" has
> Ralf> a completely different name.
>
> Ralf> At least I have found myself having to explicitly put 
> Ralf> AR = @AR@ 
> Ralf> into all Makefile.ams to get the correct ar for cross-toolchains.
>
> I believe this is no longer needed in CVS Automake (HEAD), since
> Automake now uses `autoconf --trace', sees the AC_SUBST
> performed by AC_CHECK_TOOL, and should therefore override its AR
> definition with yours.