Re: libs.am/AR = ar

[Ralf Corsepius]

Am Mit, 2002-05-08 um 20.50 schrieb 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 am currently using GNU/GCC-toolchains, which all are using binutils'
ar. AFAIK, all these target-specific all are sufficiently compatible if
not basically identical, but I am not sure :)

> >(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.
Good point.
 
> 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.
It matters if using non "unix"-toolchains, e.g. if using <target>-ar
wrappers to some other ar-equivalent or if using sym-linked toolchains
(target-ar being a symlink to, rsp, copy of another another otherwise
sufficiently call-compatible tool).

Both situations are not uncommon in embedded development.

> > 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.
In this particular case, I am using stock automake-1.6.1+autoconf-2.52.

(autoconf-2.53 is not applicable, because autoconf-2.53's PACKAGE_*
defines causes conflicts and because of autom4te.caches blowing up the
source-tree size from ~80MB to >160MB and no auto*tool wanting to remove
them.)

Ralf