I'm game.
> I would like to keep the system as RPM'ized as
> possible by upgrading packages with RPMs, but I realize that some packages
> may not be currently available like this. According to my system, here is
> what I have installed as opposed to what the documentation is saying that
I just forgot about RPM. Easier to keep up with the bleeding edge ;-)
> I have:
>
> Package I Have Required
> ------- ------ --------
>
> -> Kernel modules modutils-2.1.55-4 modutils-2.1.85
Needed. kerneld won't compile on >= 2.1.90, and isn't needed anymore.
Specify kmod support instead, and run a "rmmod -a" from cron each couple of
minutes (kmod does no unloading).
> Binutils binutils-2.8.1.0.1-1 2.8.1.0.23
You need 2.9.1.0.4 for glibc based systems (like RedHat-5), AFAIK
> -> Linux C Library libc-5.3.12-25 5.4.44
> Dynamic Linker (ld.so) ld.so-1.9.5-5 1.9.5
Irrelevant, you'll be using glibc.
> -> Procinfo procinfo-0.11-1 13
> -> Mount mount-2.7f-1 2.7l
> -> Net-tools net-tools-1.33-4 1.45
procinfo and net-tools get pretty confused by changes in /proc, so you have
to upgrade them
> -> PPP ppp-2.3.3-2 2.3.5
This one breaks badly on newer kernels.
> All of the packages with arrows next to them look like they need to have
> newer versions installed. If I install the newer version, will it not
> allow my existing 2.0.34 kernel to work properly?
Can't vouch for all of them (left 2.0.x behind a long time ago), but at
least modutils works fine. You can just keep the old kerneld, I believe it
works even with the other tools. OTOH, I still keep the binaries I compiled
under 2.1.85. And there have been patches to modutils posted that fix the
compilation problems. mount works fine too; and the binutils are really
kernel-independent. They fix some problems with the older binutils that
can make a difference for building new kernels.
> Is there a way to have
> both kernels working on the system, without having to repartition the
> drive?
Yes. In /etc/lilo.conf you can specify several kernels to boot, and you can
tell lilo which one to choose when booting. It's what I run at home, BTW:
Some 5 different kernels at hand. Note that you need some patches to get
linux to configure in 2.1.102 and 2.1.103 (a missing file in the sound
configuration stuff).
> Also, I've heard folks talking about gcc, pgcc and egcs. I'm
> assuming that these are all C compilers, but what's up with them? I
> thought gcc was the compiler that we currently use. Is there a movement
> underway to switch to a new standard C compiler for Linux?
pgcc is a split off gcc specifically aimed at generating better code for
i586/i686; egcs is another split handled by the Cygnus people, with initial
aim at a standard conforming C++ compiler, but also including a cleanup of
code generation and better optimization. They have been gathering and
including some of the Pentium optimizations from pgcc too (not everything
there fits cleanly into the gcc optimization framework (which is designed
far wider reaching than just intel CPUs), and some of it is plain broken).
Cygnus is a company that lives from supporting gcc on weird platforms
(mostly embedded stuff), and all seems to point to them just taking over
future GNU compiler development (the pace was just _way_ too slow for them:
2.7.2 is dated Nov 29 1995, 2.8.0 is Jan 14 1997. The 2.7.2.x releases
where just showstopper bug fixes. In the meantime, C++ changed a lot, and
the i386 support in gcc was rather bad. And ix86 was probably the most
popular platform for gcc (Linux had its part in this popularity, to be
sure. But other ix86 Unices and even Windows had their share), so having a
bad compiler there was just a shame). Look at <http://egcs.cygnus.com> for
details on egcs. The RedHat people have decided to ship RedHat-5.1 with
egcs-1.0.3 instead of FSF gcc, AFAIK.
OTOH, Linus still uses gcc-2.7.2.3 personally...
-- Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu