[Top][All Lists]

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

Re: Warn on naked cross-tool names, add macros to detect target tools

From: Paolo Bonzini
Subject: Re: Warn on naked cross-tool names, add macros to detect target tools
Date: Sat, 20 Mar 2004 08:59:45 +0100

> > Also, what about compiling on build=i686 for host=i386?  Then compiling a
> > simple test program will work, but a more complex one may cause problems
> > like using new instructions (cmov) or sse math.
> I think you mean the other way around, build=i386 host=i686.

No, I really meant what I wrote.  If I built the native compiler on a
build=i686, there's no guarantee that a downgraded build for host=i386 will
not contain things like CMOV.  By using an unprefixed name for a downgraded
build, you are looking for trouble.

If it was build=i386 host=i686, then, yes, that should be mostly ok.  But you
have no guarantee that the code is really being compiled for i686 and not for
i386, defining __i686__ etc.  This makes a big change for example for inline
assembly: for example GCJ uses xadd and cmpxchg to implement locks under i486
or higher, so you'd get incorrect or inefficient code unless using a real
compiler.  Again, that's looking for trouble, even though it should stay well
hidden in general.

For downgraded or upgraded builds, you should either specify at least two
flags options (for the compiler, and for the preprocessor in case there are .S
files) *as well as* --host (to invoke cross-compilation mode); or, just set up
a prefixed tool name (possibly a symbolic link, or a simple shell script
wrapper) and specify --host.  It looks to me that the second option is easier
to use, though maybe a bit more complex to set up.

> I believe it's always
> worked in the past just to have one's PATH setup with suitable cross
> tools

It might have worked badly in the cases I explain above, and it definitely did
not work when a package had to compile tools that run on the build system.
Since I'd like Autoconf to be able to find a CC_FOR_BUILD, I think that's
another reason to not use prefixed cross tool names.

> and I think that can usefully remain
> for compatibility if for no other reason.

That's why there's a deprecation period during which people can adapt their
configuration (or at least learn that they will have to).


reply via email to

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