gcc-2.91.1 problems in kernel building/ installing multiple versions of gcc/egcs

pj pauljohn@ukans.edu
Tue Sep 21 17:26:00 GMT 1999


I run RedHat 6.0 and I grabbed gcc-2.95.1, first from the varesearch site (ftp.varesearch.com/pub/support/hjl) and later I grabbed the SRPM from RedHat's rawhide section (that one is gcc-2.95.1).  With all of these versions of gcc-2.95.1 installed in place of egcs, I find many things compile well, but not kernel modules.  I saw some assertions in www.dejanews.com that there is some fundamental problem with the linux kernel's types.h file and something called asm.  I've found removing the gcc-2.95.1 rpms and reinstalling egcs does allow me to compile kernel modules, the same ones that make gcc-2.95.1 barf.  If you need some detailed examples of this error, I can provide it, but it seemed from www.dejanews.com that this is a known problem.

Well, is it "widely known"?

Anyway, I decided to rebuild gcc-2.95.1 with the prefix /usr/local, so it could coexist on my system with the egcs RedHat gives out in the distribution.  All went well, except for this.  Both egcs and gcc create versions of cpp, and both of those cpp packages want to insert a link /lib/cpp that points to their executable.  As a result, these two versions of cpp cannot be installed without wrecking one or the other.

Does it matter?  Why the heck does the RPM's spec file create that symlink in the first place? I've not built or installed gcc from source before, so perhaps this is obvious, but why do these RPMs create this symlink in /lib?  That seems peculiar to offer up an executable in /lib.

 Thanks in advance if you have any ideas for me.

Paul Johnson
Assoc. Professor
Dept. of Political Science
University of Kansas


More information about the Gcc-help mailing list