automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libs.am/AR = ar


From: Andy Helten
Subject: Re: libs.am/AR = ar
Date: Wed, 08 May 2002 14:50:24 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2


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.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]