[gentoo-amd64] Re: gcc in a multislot

[Duncan]

"P.V.Anthony" <pvantony@×××××××××××.sg> posted
49AA7ABD.2040706@×××××××××××.sg, excerpted below, on  Sun, 01 Mar 2009
20:08:29 +0800:

> I need to have two gcc. One the standard, that comes with gentoo. The
> other that is needed only gcc with vanilla flag.
>
> In a harden gentoo, there is more than one gcc and the gcc can be
> selected by using gcc-config.
>
> In the current server, there is only a standard gentoo gcc. I would like
> to install a gcc with vanilla flag. Plus be able to select them using
> gcc-config.
>
> The gcc should be the same version.
>
> How can this be done?.

Normally, the gcc-version is what gcc-config changes and you'd need to 
have at least a micro-version (4.3.0, 4.3.1, and this would require 
USE=multislot or it'd be 4.2 and 4.3) difference.

However, gcc-config also changes what (IIRC) are called the spec files, 
which give gcc some defaults to work with, without having to put it all 
in the C(XX)FLAGS.  Normally these will be system-wide and there's only 
one per version, but based on various things I've read including your 
comment above, hardened apparently sets up (at least) two spec files for 
each version, a hardened and a normal config, allowing you to switch 
between them.  This is somewhat different than a vanilla gcc, however, 
since it's switching the spec file, but (I believe) using the same gcc 
binary as compiled from the ebuild -- I do not believe it actually 
compiles gcc twice, hardened and normal, just changes the spec file 
invoked when gcc is called.

I'm not familiar with hardened or with the spec files or the technology 
behind them directly, so that's about all I know.  However, it should be 
possible to start from a gcc ebuild and follow the code path from there 
back thru the eclasses, the hardened profile, and gcc-config itself, to 
see what exactly gcc-config does and how it switches versions and spec 
files, and use that to create manually a gcc-config profile to switch 
between gcc-gentoo and gcc-vanilla as appropriate.

However, a MUCH simpler approach would be to copy one of the gcc ebuilds 
to your overlay, then reversion it to something like say 4.3.99 
(something quite unlikely to actually appear, thus causing a versioning 
conflict) but setup so it uses the 4.3.3 (or whatever) sources.  You 
could then use USE=multislot to get them both slotted onto your machine, 
setting one up with USE=vanilla as well.  That would setup a gcc-config 
profile for both, so you could switch between them as you normally 
would.  This is what I'd try here if I were doing it as it should be a 
relatively straightforward ebuild hack to create an overlay 4.3.99 or 
whatever out of 4.3.3 or whatever, and the rest is easy enough with 
USE=multislot for both and USE=vanilla for one of the two, with gcc-
config and the package management system (portage or alternative) doing 
the rest.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman