[csw-maintainers] Reasons for gcc to have a separate prefix

[Maciej Bliziński]

2011/8/27 Dagobert Michelsen <dam at opencsw.org>:
>> The annoying part of this plan is that you have to recompile the old
>> version of gcc to make it available, you can't just let the packages
>> be.  When you replace gccN with gcc(N+1), you have to make the extra
>> effort of moving gccN into own prefix.  I consider it a reasonable
>> trade off.
>
> What about the "jdk" technique to always package with prefix and link CSWgcc in
> /opt/csw/bin to the latest or as alternative? This would sacve repckaging on
> update.

There is a problem with that. We want the libraries to be installed in
/opt/csw/lib, even though the rest of the package would be under
/opt/csw/gcc4.  During compilation, gcc looks for its includes
relative to the libdir.  The includes live under
$(prefix)/include/..., so there's a bit of code in the gcc build
system to calculate the relative path going from the libdir to the
include dir.  This function uses a set of regular expressions, which
in our case (prefix=/opt/csw/gcc4, libdir=/opt/csw/lib) do not
calculate the right answer.  As result, g++ fails to find the include
files.  We could try to fix this function, but I don't know what their
other corner cases are, so there's a lot of potential of breaking
builds for other people.

I'm suspecting that we could support multiple versions by adding a
prefix to the binary names and providing symlinks for them. For
example (not literal symlinks, but something to give you the idea):

--binary-prefix=gcc4

/opt/csw/bin/gcc → gcc4gcc
/opt/csw/bin/g++ → gcc4g++
...

Maciej