This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Updating top-level autoconf to 2.59


I hope the GCC people will correct me if I get this wrong, but here is
my recollection of the gcc/binutils behavior:

First, both gcc and binutils have (in effect) two build "modes": native
and cross. When no --target is specified, tools are built, named, and
installed for the host. This case covers:

   ./configure
   ./configure i386-unknown-elf

I am not certain what happens when i386-unknown-elf does not match the
host architecture. My guess is that (a) tools are built that target the
specified configuration, but (b) they are installed under the host tool
names. This outcome is non-obvious, but it is useful to be able to have
this outcome occasionally and there is another usage that deals with
target renaming.

The other invocation is

   ./configure --target=xx-yy-zz

which builds for target xx-yy-zz and installs the tools as
xx-yy-zz-tool.

When --target is specified, the standard tool names definitely MUST NOT
be installed! First, those may already exist in the target directory.
Second, installing them is an invitation to disaster in a cross
environment (unchecked invocation of wrong compiler).

If it is desired to install a same-host cross compiler under non-munged
names, either configure and build the first way or add some option like
--host-too to govern this.

shap

On Thu, 2007-02-08 at 14:47 +0000, Joseph S. Myers wrote:
> On Thu, 8 Feb 2007, Daniel Jacobowitz wrote:
> 
> > > ... this, which was likely implemented without any discussion with 
> > > people really building cross tools.
> > 
> > Speak for yourself - I like this, despite the migration challenge.
> > It's useful for uniformity of a set of cross tools, one of which may
> > just happen to match $host.
> 
> I think:
> 
> * Uniformity should mean that $target-$tool is *always* installed, 
> regardless of whether or not native (GCC does this for at least some 
> tools, I don't think binutils does).  Plain $tool should be installed when 
> native as well.
> 
> * Whether one of (build, host, target) is specified explicitly should not 
> cause any difference in behavior from it being defaulted from another one 
> of them or from config.guess.  This means you can choose to completely 
> ignore what the defaults are and be explicit about everything.
> 
> * If you want to build an explicitly cross tool despite host == target, or 
> act like you are cross compiling despite build == host, or build a native 
> tool (i.e. one using the native directory layout and installed as plain 
> "gcc") despite host != target, or act like you aren't cross compiling (so 
> can run execute tests for $host) despite build != host, these should be 
> determined by explicit configure options; not by which of build, host and 
> target where specified explicitly and which were defaulted.  (And not by 
> older autoconf's experiments to see if it can execute a program built for 
> the host.)
> 
-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC
+1 443 927 1719 x5100


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]