> 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 --------------------------------------------------- PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us To subscribe, unsubscribe, or to change your mail settings: http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss