> I've been thinking about this recently. What qemu does is compile a C > implementation of the target processor's instruction set into an object > file when qemu is built, then at run-time (JIT time) it cut-n-pastes > bits of that object file when it "compiles" the target executable into > native code that can be executed directly in the emulator. This is > pretty cool, as it means you have a cross-platform target emulator that > is fast because it leverages the compiler to write the emulation code, > without having to maintain separate implementations for each target. > > However it does rely on the ability to snip the function > prologue/epilogue reliably so you can stitch stuff together (in > particular the return instruction is eliminated), and with gcc-4 this is > no longer possible because the return is not always and only at the end > of the function. I think the change to gcc that causes this is one of > the reasons the major revision number was increased. > > The reason for describing this is to illustrate that qemu is not > "broken" as such; it just relies on implementation detail of the pre-4 > gcc series. Since gcc-4 doesn't provide any option to force code > generation to fit the requirements of qemu, the compilation of the > affected code must use gcc-3 (which it does with a very specific set > of CFLAGS). Note; the majority of qemu can be compiled with gcc-4 just > fine, however the target implementation objects have to be built with > gcc-3 because gcc-4 does not provide an option to get the old gcc-3 > behaviour.
You take the words out of my mouth. That is exactly, what i'm after. Actually i know, that there are aware of problems that may be caused by using different compilers for different parts of software. But for qemu, this is possibly a must. While gentoo-ebuilds will still complain and force people to switch gcc by hand, other distros may simply offer a qemu built with a different gcc-version than the system-wide one. > Since we already have slotted gcc working just fine, it seems > reasonable to me that we could support packages requiring the existence > of more than one compiler version (although I'm not sure portage > DEPENDs will cope - I'm guessing: > > DEPEND="<sys-devel/gcc-4 > >=sys-devel/gcc-4" > > won't be interpreted to mean both a pre-4 and a post-4 compiler are > required). I think, this does what you don't expect it to do. I remember a bug, where a maintainer wanted to depend on a package, but only a certain version-interval. He used exactly something like you wrote it above. In the end, two versions of the package were installed, and some people agreed on the necessity for a syntax for a version-interval. (which is still not in portage 2.1 afaik)
signature.asc
Description: OpenPGP digital signature
