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