This one time, at band camp, Yaroslav Halchenko said: > > It was a mail to -devel, and I mispoke, it was aranym, not qemu, > ;-) ok - getting closer to the true story here, but unfortunately I > could not locate any 'failed build' email in the -devel from him within > any reasonable timeframe where he would mentioned failed build. But I've > found > http://lists.debian.org/debian-devel/2006/12/msg00084.html > where he describes "quite reliable" setup ;-) The message is here: http://lists.debian.org/debian-devel/2007/02/msg00241.html > > It could certainly be a bug in the toolchain, or a bug in the emulator, > > or a bug in the original source code. I'm not really sure it matters, > > though. Increasing the likelihood of building bad binaries for little > > gain doesn't seem like a good risk vs. gain assessment to me. > yikes... if you got a bad apple it doesn't mean that an orange in the > near-by basket is rotten as well... > > The discussion is either it is as reliable to use emulator (QEMU in > particular) as the real box. You brought an example where build process > under emulator failed. I mentioned that it might be not emulator false > but build chain and you pretty much agree to that. So how that > brings emulator under question of its equivalence in terms of building > packages to the real box? > > And actually failed build is better IMHO than ok-build using flawed > build tool, since it allows to detect/debug/eliminate the problem. > So, to summarize, is possible to extract now from your statement > that real arch promotes building 'bad binaries' ;-) Er, you seem to have read what I said backwards, so perhaps I wasn't clear. I am saying that if the emulated environment can be shown to differ from a real CPU in any but the most trivial of ways, I am uncomfortable with it. It may be a bug in the emulator, a bug in the toolchain, or the wrong color of sacrificial goat. When you get different results in an emulated environment, it leads me to believe that reproducibility will suffer. The fact that it failed to run the binary correctly in this failure instance is good. But another day, it may fail to correctly run gcc, and that would be bad if it exited 0 with a wrongly built binary. -- ----------------------------------------------------------------- | ,''`. Stephen Gran | | : :' : sgran@debian.org | | `. `' Debian user, admin, and developer | | `- http://www.debian.org | -----------------------------------------------------------------
Attachment:
signature.asc
Description: Digital signature