RE: autoconf usage question

["Povolotsky, Alexander" <Alexander dot Povolotsky at marconi dot com>]

>Can you give more context?  How did the question come up?

I noticed that, possibly due to "misconfigured" (non-standard,
non-conventional) placement of the s/w   
 (compiler, binutils, libraries, includes) on my system, which has both
native and cross-compiler gcc,
 unless I use the shell script with env vars, pointing to the right
"full-path",
 the ./configure does not "guess" correctly that "user wants" the native
compiler to be used
 (rather then cross-compiler), even with the "options hint",
having all 3 options (--build, --host and --target) being all set pointing
to the "native" architecture ...

The ./configure still picks the wrong compiler, fails the tests, pics wrong
incudes, etc ... .
Also the "cache persistency" is the problem (IMHO) - if the options or env
vars got changed - the "cached info"
needs to be not used by "configure' ... (at least I would like to have such
behaviour)  

-----Original Message-----
From: Daniel Kegel [mailto:dank@kegel.com]
Sent: Tuesday, October 19, 2004 3:11 PM
To: Povolotsky, Alexander
Cc: 'crossgcc'
Subject: Re: autoconf usage question


Povolotsky, Alexander wrote:
> If downloaded package has "configure" script generated by the "older"
(than
> available on the "host" computer} 
> version of "autoconf" - could such "configure" script be "upgraded" on the
> "host" computer ?

Not unless you run into a problem that can't be solved any other way.
Autoconf is a bit fragile, best not mess with it unless you're
serious.

Sometimes I backport tiny fixes into the configure script as
patches to avoid having to run autoconf.

Can you give more context?  How did the question come up?- Dan

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com