gcc32 and kgcc

[Michel Alexandre Salim]

On Sun, 2003-09-28 at 09:20, Carlos Rodrigues wrote:
[snip]
> My suggestion is a "kgcc" symlink. This "kgcc" would be sure to exist 
> from now on, pointing to "gcc32" now but maybe pointing to "gcc" in the 
> future when all gcc 3.3 issues in the kernel are eliminated. This means 
> that now it would be provided in the gcc32's rpm but in the future it 
> could change to gcc's (there could even be a "Provides: kgcc"). If this 
> ends up in other distros (or as a requirement in the LSB) it would mean 
> that modules could simply rely on the existence of "kgcc" and be free 
> from this "CC=gcc32" stuff (at the very least the nvidia guys could just 
> add a check for kgcc to fix things on Red Hat/Fedora and never bother to 
> look at it again).
> 
[snip]
Amen to that. I'm still on Severn1 - an annoying side-effect of
downloading with BitTorrent is that I have 99% of the first two ISOs
already downloaded but somehow the program is now busy downloading
mostly the third ISO :) Gaah.

There is a problem with your suggested approach though - as it stands,
if Red Hat suddenly discover a problem with the main system compiler (as
it did between Severn1 and Severn2), the main compiler RPM would still
erroneously be 'providing' kgcc. A virtual package 'kgcc' containing a
symlink to either gcc or (say) gcc32 would work fine; when there is a
problem building a kernel, just provide a new kgcc that links to a
different compiler binary and Requires: it.

I'm still a bit puzzled by the fact that the two latest Rawhide
kernel-source RPMs still have gcc as their compilers in their Makefiles.
RedHat certainly did not build kernels in that series using plain gcc,
since whenever I built a custom kernel I could not get pcmcia to work...

Regards,

Michel