[gentoo-dev] Re: using specific gcc-version in ebuild

[Sven Köhler]

> 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)