gcc and glibc

[Nathan England]

> Hey Nathan - How'R ya?
>
> slamd supposedly has the fixed glibc for various types of segfaults (Xlib,
> swap, modprobe) due to some of the shared libraries issues (32/64 etc.)
>
> http://www.slamd64.com/
>
> Neither LFS or BLFS recommend that you try to build or upgrade yourself:
>
> A Package Manager makes it easy to upgrade to newer versions when they are
> released. Generally the instructions in the LFS and BLFS Book can be used
> to
> upgrade to the newer versions. Here are some points that you should be
> aware
> of when upgrading packages, especially on a running system.
>
>    -
>
>    If one of the toolchain packages (Glibc, GCC or Binutils) needs to be
>    upgraded to a newer minor version, it is safer to rebuild LFS. Though
> you
>    *may* be able to get by rebuilding all the packages in their dependency
>    order, we do not recommend it. For example, if glibc-2.2.x needs to be
>    updated to glibc-2.3.x, it is safer to rebuild. For micro version
> updates, a
>    simple reinstallation usually works, but is not guaranteed. For
> example,
>    upgrading from glibc-2.3.4 to glibc-2.3.5 will not usually cause any
>    problems.
>    -
>
>    If a package containing a shared library is updated, and if the name of
>    the library changes, then all the packages dynamically linked to the
> library
>    need to be recompiled to link against the newer library. (Note that
> there is
>    no correlation between the package version and the name of the
> library.) For
>    example, consider a package foo-1.2.3 that installs a shared library
> with
>    name libfoo.so.1. Say you upgrade the package to a newer version
>    foo-1.2.4 that installs a shared library with name libfoo.so.2. In this
>    case, all packages that are dynamically linked to libfoo.so.1 need to
> be
>    recompiled to link against libfoo.so.2. Note that you should not remove
>    the previous libraries until the dependent packages are recompiled.
>
> http://www.linuxfromscratch.org/blfs/downloads/6.1/blfs-book-6.1-nochunks.html
>
> I would move off your content and build a new distro when your glibc is no
> longer fresh.  A reasonable expectation for every build without package
> management (depending on distro and production use) is 4 years before
> rebuild.   If this is a production server, you can lay on a build on
> replacement media to minimize downtime, but generally, it's easier to
> build
> a replacement, migrate over and test your daemons, binaries or systems,
> change the IP address and clear the arp cache and switch over/turn down,
> then rebuild your old system.
>
> I would not build a system from scratch, beit anything short of
> glibc-2.3.5
> and recommend 2.8 (although that's just from research not recent
> experience
> - another will tell you experience from this list I hope?).
>
> http://www.roseindia.net/linux-distribution/LinuxFromScratch6.2
>
> Further, I would not build a system from scratch for anything terribly
> prone
> to fuzzing, or use standard LFS hardening techniques (another book).
>
> --
> (623)239-3392
> (503)754-4452 www.obnosis.com
> http://www.obnosis.com/motivatebytruth/gnu-people.jpg
>

Lisa,

I appreciate the input. I am upgrading from glibc 2.7 and wanted to
attempt to try out the latest. I might go back to 2.7 or try 2.8, but I
wanted some input from others. I was also using gcc-3.4 and went to
gcc-4.3. I have always tried to avoid 4.3 as it seemed there were so many
problems, but that was because the headers were updated and a lot of
software was never updated for it, instead patches were issued. I'm very
reluctant to attempt to use 4.4...

I just might revert back to everything previous, but since I managed to
wipe out my entire home backup... other thread... I figure I don't have
much to lose!!! ha ha

10 years worth of work shot in one failed backup attempt! argh!

You recommend glibc-2.8 ? I will look into that.

nathan