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

[Kevin F. Quinn]

On Fri, 16 Jun 2006 15:30:06 -0400
Mike Frysinger <vapier@g.o> wrote:

> On Friday 16 June 2006 15:10, Sven Köhler wrote:
> > some software, like qemu and others, are simply not compatible with
> > gcc 4.x and they will not become compatible due to severe
> > conceptional issues.
>
> then they stay broken ... add a warning to the ebuild if
> `gcc-major-version` is "4" (see toolchain-funcs.eclass)

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.

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

Portage DEPENDs aside, it would be relatively easy to provide a
function to return the latest 3-series compiler. We already have
symlinks installed in /usr/bin (e.g. i686-pc-linux-gnu-gcc-3.4.6) -
caveat that they don't use the wrapper, although that may not matter.

Absent the DEPEND functionality, we can still go quite a way just by
supplying a suitable function or functions in toolchain-funcs.eclass.
The affected packages can use them in pkg_setup to check for existence
and abort if they're not available without requiring the user to change
the system default compiler.  The only loss is that the user doesn't
find out about the missing dependency until the package is actually
merged, rather than at the beginning of an 'emerge world'.


Perhaps details should be taken off-list, if we're to think about this
seriously.

-- 
Kevin F. Quinn