Mailing List Archive

I've been pretty busy this summer and haven't had much time to devote to
the gcc-config changes we discussed here a couple months back until
yesterday. I created a cvs repository for the development in
gentoo/src/toolchain/gcc-config. Right now, it's barely more than
framework for the code and a README detailing some aspects of the
program (specifically changes from the current 1.3.X line). I'm not
worrying about a migration path right now, but it shouldn't be too
difficult. The only major headache I can think of is someone
downgrading.

The configuration files are in XML. I'm a little apprehensive about
having such a core package depend on an outside library like this, but I
think having the xml configuration files allows a much more robust
configuration. Plus, we can use USE=static. I don't have much
experience dealing with creating dtds or the libxml2 API, so if someone
else would like to help out with implementing that part of the code, I
would appreciate the help... but I'm not expecting that to hold me up
too much if nobody volunteers.

Along with moving to this new gcc-config, we should address the "gcc
upgrade la hell" problem. az and I talked about this a few times, and
we came to the conclusion that deleting the .la files installed by gcc
would be the best option. See bug #75420 comment #34 and
http://ramblings.hudscabin.com/blogs/index.php/2005/05/02/multilib_and_toolchain_thoughts for a little more...

Here's the current README. I welcome comments, criticisms, concerns,
and assistance as I start implementing this.

--Jeremy

gcc-config 2.0

gcc-config 2.0 is incompatible with previous versions of gcc-config. A
migration path has not been implemented yet.

With gcc-config 2.0, the configuration options have expanded. The
wrapper now
uses the configuration find the execuatble to fork off rather than
searching through
the $PATH. Each CHOST has a profile associated with it. The CHOST used
by the wrapper
is determined by the first matching criteria:

1) If the ABI environment variable is set, and CHOST_${ABI} is also set,
it will be
used. This is a deprecated feature and is really only here for
backwards
compatibility. It will be removed once all ebuilds and profiles
relying on this
feature have been removed from portage.
2) If the executable is called with a CHOST prefix, it is used.
3) If the CHOST environment variable is set, it is used.
4) The default CHOST is used.

configuration directory: /etc/gcc-config
All configuration information is stored in this directory. The current
config
format is as follows, but it is subject to change before release.

The selection file (/etc/gcc-config/selection.conf) lists the currently
selected
profiles for each CHOST handled by gcc-config. It is formatted as
follows:
<selections>
<default_chost>##DEFAULT CHOST##</default_chost>
<selection>
<chost>##CHOST##</chost>
<version>##gcc version being used##</version>
<profile>##profile name##</profile>
</selection>
<selection>
...
</selection>
...
</selections>

Configuration file (for each installed gcc package) is
named /etc/gcc-config/<version>.conf formatted as follows:
<gcc_profiles>
<version>##version##</version>
<binpath>##Path containing binaries to execute when using this
profile##</binpath>
<infopath>##Where the info pages are##</infopath>
<manpath>##Where the man pages are##</manpath>
<profile>
<name>##Profile Name##</name>
<chost>##Default CHOST for this profile##</name>
<spec>##GCC specs file to use##</spec>
<ldpath>##Path to add to ld.so.conf##</ldpath>
<cflags>##additional CFLAGS to prepend to the command line##</cflags>
</profile>
<profile>
...
</profile>
...
</gcc_profiles>

Note that the <chost> in <profile> is only used as a way to tell the
user what this profile is used for.
The <chost> set in the <selection> tag determines how the binaries act.
The <default_chost> in the <selections>
tag determines how the binaries 'gcc', 'g++', etc (that is the ones
without a prefix) behave.

Example /etc/gcc-config/master.conf:
<selections>
<default_chost>x86_64-pc-linux-gnu</default_chost>
<selection>
<chost>x86_64-pc-linux-gnu</chost>
<version>x86_64-pc-linux-gnu-3.4.4</version>
<profile>amd64-vanilla</profile>
</selection>
<selection>
<chost>i686-pc-linux-gnu</chost>
<version>x86_64-pc-linux-gnu-3.4.4</version>
<profile>x86-vanilla</profile>
</selection>
<selection>
<chost>pentium4-pc-linux-gnu</chost>
<version>x86_64-pc-linux-gnu-3.4.4</version>
<profile>p4-vanilla</profile>
</selection>
</selections>

Example /etc/gcc-config/x86_64-pc-linux-gnu-3.4.4.conf:
<gcc_profiles>
<version>x86_64-pc-linux-gnu-3.4.4</version>
<binpath>/usr/x86_64-pc-linux-gnu/gcc-bin/3.4.4</binpath>
<infopath>/usr/share/gcc-data/x86_64-pc-linux-gnu/3.4.4/info</infopath>
<manpath>/usr/share/gcc-data/x86_64-pc-linux-gnu/3.4.4/man</manpath>
<profile>
<name>amd64-vanilla</name>
<spec>/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/vanilla.specs</spec>
<ldpath>/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4</ldpath>
<cflags>-m64</cflags>
</profile>
<profile>
<name>amd64-hardened</name>
<spec>/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/hardened.specs</spec>
<ldpath>/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4</ldpath>
<cflags>-m64</cflags>
</profile>
<profile>
<name>x86-vanilla</name>
<spec>/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/vanilla.specs</spec>
<ldpath>/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/32</ldpath>
<cflags>-m32</cflags>
</profile>
<profile>
<name>p4-vanilla</name>
<spec>/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/vanilla.specs</spec>
<ldpath>/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/32</ldpath>
<cflags>-march=pentium4 -m32</cflags>
</profile>
</gcc_profiles>