Feature #2786
OI should enable multiple gcc versions at a time and store gccruntime in private directories
100%
Description
OI should not lock down to a single gcc version at a time.
This makes live worse for users wanting different versions of gcc for self compiling F/OSS.
As well all parts of the distro are forced to always use the same gcc version at a time.
Currently available is gcc 4.4.x in fixed location /usr/bin/ and /usr/lib
Wanted is:
It should be possible to have multiple gcc versions available at a time for different use cases, including personal preference of the local user. If a new gcc version appears it can be made availble immediately for testing and slow migration of projects to the new compiler version.
To achieve this, gcc should tell binaries it compiles to load the gcc runtime libraries by default from a specific private and versioned directory containing the runtime of the same version then the compiler was.
Other projects successfully using this concept are able to run their own gcc versions without interference with the distribution or competing. Examples are pkgsrc, SFE and OpenCSW (probably some more).
Example:
directory layout for gcc 4.4.x:
/usr/gcc/4.4/bin for binaries /usr/gcc/4.4/lib for compile time libraries /usr/gcc/4.4/lib gcc-runtime libraries for compiled user programs
and on the same system at the same time,
directory layout gcc 4.7.0:
/usr/gcc/4.7/bin for binaries /usr/gcc/4.7/lib for compile time libraries /usr/gcc/4.7/lib gcc-runtime libraries for compiled user programs
optionally there can be mediated symbolic links by default. Replace "4.7" with the most fresh version currently installed.
Use case is, a program can tell to use just the default gcc configured for the local machine.
As well, independently of the gcc version, gcc runtime libraries can be found in this location.
/usr/gcc/bin/gcc -> /usr/gcc/4.7/bin/gcc /usr/gcc/bin/g++ -> /usr/gcc/4.7/bin/g++ /usr/gcc/lib/libgcc_s.so -> /usr/gcc/4.7/lib/libgcc_s.so /usr/gcc/lib/libstdc++.so.6 -> /usr/gcc/4.7/lib/libstdc++.so.6
Programs compiled with a gcc compiler do search in this order for runtime libraries:
(major.minor is the gcc compiler version the program was compiled with)
/usr/gcc/<major.minor>/lib/
/usr/gcc/lib/
/usr/lib
/lib
That way a program can be transferred to another installation and go through the library directories until the gcc runtime is found (hopefully a compatible one, but that is a problem local to gcc and how it maintains ABI compatibility itself).
Users wanting a specifiy gcc version (and implicit use the matching runtime libraries in the compiled binaries)
simply set the CC and CXX variable with an absolute filesystem path or use the PATH variable.
Example to get the 4.7 version, in this example with unmodified PATH variable:
export CC=/usr/gcc/4.7/bin/gcc export CXX=/usr/gcc/4.7/bin/g++
Example to get the 4.4. version, in this example PATH variable is modified:
export PATH=/usr/gcc/4.4/bin:$PATH export CC=gcc export CXX=g++ ./configure --prefix=/usr make && make install
In /usr/lib there are no gcc runtime libs by default, but in complicated cases
there can be compatibily symbolic link in case a program is imported from
outside of this machine and distrobution, and setting LD_LIBRARY_PATH is not
possible or allowed to be used to point to the gcc runtime library version of choice.
Note: using LD_LIBRARY_PATH is ususally considered a bad idea.
Then there can be mediated symbolic links:
/usr/lib/libgcc_s.so -> /usr/gcc/lib/libgcc_s.so
or alternatively to explicitly use for all the 4.4 version runtime:
/usr/lib/libgcc_s.so -> /usr/gcc/4.4/lib/libgcc_s.so (same for libstdc++.so.6)
Packaging of gcc should be split into several packages:
gcc-44-runtime (runtime only 4.4.x) gcc-44 (compiler 4.4.x) gcc-47-runtime (runtime only 4.4.x) gcc-47 (compiler 4.7.x) pointing with mediated symlinks to the local administrator default compiler version (points by default and automaticaly to 4.4 or 4.7) gcc-runtime (mediated symlinks only) gcc (compiler) (mediated symlinks only) compatibility pacakge with this use case: programs imported from outside and not using LD_LIBRARY_PATH can get the gcc runtime in /usr/lib as an exception gcc-runtime-compat (mediated symlinks only) compatibility package with this use case: get a mediated symlink /usr/bin/gcc and g++ pointing to a specific gcc version, this leads to no changes to configure/Makefiles of inflexible projects *if* CC/CXX or PATH is not honored at all (luckily enough those cases are very rare, one out of thousands!) gcc-compat (mediated symlinks only)
Transitioning:
With the new compiler directory layout and LINK_LIBGCC_SPEC, the old binaries continue to use the old locations for gcc runtime.
The first binaries with the new layout start themselves loading the gcc runtime from the private location.
To serve the consumers of the old library location the gcc-runtime-compat with symlinks pointing to the apropriate gcc runtime version can be used. If the last consumer of that location is gone, then installation of gcc-runtime-compat is being optional and only
needed for programs coming from outside of the distro.
More to read and perfectly working implementations can be found with pkgsrc, SFE (google: SFEgcc.spec LINK_LIBGCC_SPEC) and OpenCSW.
Files