[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: libs.am/AR = ar
Re: libs.am/AR = ar
09 May 2002 05:46:10 +0200
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:
> 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.
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