Re: [Qemu-devel] [Bug 929638] Re: qemu 1.0 unable to compile on the pandaboard ES

[Paul Brook <paul@codesourcery.com>]

> > I'd rather not.  If at all possible we should avoid runtime tests.  Even
> > for "native" systems they generally give the wrong answer as the machine
> > you're building on often isn't the one you will be running on.  If we
> > know arm hosts are broken then that's what we should test for in
> > configure (with a comment saying why).
> > 
> > IMO consistency between builds for the same target environment is more
> > important than opportunistically probing in a native builds.
> 
> I agree for CPU features, sure. Anything that would be influenced by your
> build system vs execution environment. But in this case we're probing for
> a feature of a library we're linking against, so runtime checks really
> aren't all that bad, since you usually want to build against the same libc
> that you're executing against later on.

Maybe, but I don't consider "assume it's broken when cross compiling" to be an 
acceptable answer.  If we can't get the same answer in a cross environment 
then I don't want to be doing it at all.

Using a native build environment is often infeasible.  The Debian/Ubuntu and 
Maemo folks do crazy things to make it happen, but often as not you're cross 
building the whole system from scratch.

Even in a desktop context, all my production builds are done with a cross 
compiler[1].  Having that cross build behave differently from a native build 
using the exact same libraries and config is liable to cause the absolute 
worst kind of bugs - the sort that only shows up in something you're about 
to/already have shipped to the customer.

Paul

[1] The build cluster runs modern 64-bit linux, but the end result needs to 
work on older 32-bit linux and windows.  There's no way I'm setting up a 
cluster of RHEL4 and windows XP machines to do native builds, but I can easily 
maintain a cross toolchain to win32 or RHEL4 i686 sysroot indefinitely.