Public SourceMage Discussion List

["David Brown" <dmlb2000 AT gmail.com>]

Little History:
I haven't been running the standard gcc set of spells for a while, I
first started running my own gcc gcc34 gcc40 gcc41 gcc33 spells (and
their corrisponding g++ spells) in an attempt to try and install them
in parallel instead of in /opt (like we currently do it) this setup
was as follows:
1.) each gcc$VERSION and g++$VERSION spell would install it's
respective gcc and g++ binaries and libs in a versioned
non-conflicting location (with --program-suffix=-$VERSION and some
other hack arounds I got this to work).
2.) The gcc and g++ spells would only by a set of symlinks to the
correct gcc, g++, and stdc++ binaries and libs for the current version
of the compiler

this was the basic setup, if you want more specifics pray to the
/dev/null god that something comes out of the bit bucket.

When I moved to just maintaining the linux spell and helping the
sorcery team I trashed the spells and moved to the standard setup that
we had in the grimoires.

Currently (since I'm working on stage root in sorcery) interest in
making that setup again (fixing my short comings before) and the
integration of the gcc34 and gcc 4.0 to test have propted me to start
making a parallel install for gcc's again. The current setup I have
right now is this:
1) the gcc and  g++ spell is the same as in the grimoires
2) the gcc$VERSION spells are svn snapshots of the gcc compilers and
they are installed to versioned binaries and libs by some of the same
methods I used in the first setup. However, I removed libgcc and
anything else installed that isn't needed for /usr/bin/gcc-$VERSION
using stage root (this thing is going to be cool once I can get it
working perfectly :) )
3) the gcc34 spell specifically installs both gcc and g++ and
libstdc++ and the static libstdc++ in versioned locations, using stage
root (again) I removed the symlinks gcc installs and moved the static
lib to a different name so it wouldn't conflict also removing libgcc
because it isn't needed.

These next few lists are pros and cons of having parallel vs. /opt
installs of gcc, these are only some of the pros and cons I know of,
this isn't a complete list.

Some of the pros I found with parallel gcc/g++ installs:

1) Easy to Use for small projects:
Since I'm still in school and most of my homeworks are little two or
three week projects (at the most) needing the same version of gcc as
the professors was a must. So using a makefile to do my project it was
easy enough to do a make CC=gcc-3.4 CXX=g++-3.4 or specify them in the
makefile then comment it out when I submitted it.

2) configure actually uses it if it needs it
Found out that some of the autotooled packages automagically picked up
on gcc-3.4 and used it if that's the version it required (unexpected
bonus!!)

3) upgrade would be faster and easier
If we went with the first setup of gcc's that would allow us to make
upgrading gcc or g++ simple, spell would be "move the symlinks" you
may have to compile the new version if you didn't already have it
installed but otherwise you'd be in the clear for about a 10 second
upgrade of gcc ;).

4) Multiple versions of gcc gives choice to the user
With my current setup I've been running a kernel built with gcc-4.1 to
test it out and see if anything breaks, if maintainers of other
packages want to take a serious look at installing smgl they would
need to have access to multiple versions of compilers so they can test
the packages they maintain, while keeping the stable system compiler
on their systems.

Some of the cons I found with parallel gcc/g++ installs:

1) Pain in the ass without stage root
Honestly it was a pain in the ass to figure out how the gcc installer
worked what to specify where to install stuff in the correct location
the first time.

2) Complicated projects make it harder
For larger packages I found it didn't work so well, no matter what I
did to the monolithic xorg 6.8.2 it would still end up using gcc
instead of gcc-3.4 and I never figured out how to make it work.  Also
larger autotooled packages required lots of var setting, CC CXX CPP
are just a few.

Some of the pros I found with /opt gcc/g++ installs:

1) Complicated packages become easier
With the current setup of changing the paths around xorg does actually
use gcc-3.4 because the shell finds gcc under /opt because of the path
variable prefix of the gcc location we want to use. This also goes for
complicated user maintained packages.

Some of the cons I found with /opt gcc/g++ installs:

1) upgrades become harder
When we go to upgrade we end up installing everything all over again
gcc/g++ 3.4 get rebuilt so they get reinstalled to /opt and gcc 4.0
and g++ 4.0 then get compiled as the new compiler, becomes a long
drawn out process to get the upgraded compiler.

The other thing I'd like to point out is most people look for gcc in
/usr/bin/gcc and expect any other version of gcc to be there, also
most distros put multiple versions of gcc installed in parallel (I
know this is a logical falicy but there has to be a reason everyone
else does it).

I'm tired of writing so if you'd like to add your own experiences or
fun with gcc installs please feel free to reply ;)

- David Brown