On Mon, Sep 7, 2009 at 5:55 PM, Nathan England <nathan@paysonlinux.org> wrote:

I have recently rebuilt my systems using gcc 4.3.4 and glibc-2.10.1 and
I've had nothing but trouble since, especially with firefox and
thunderbird, neither of which seem to run for more than a minute before
segfaulting with NO information output at all...

A complete analysis of the stack trace and segdumpfile would probably provide more information, however, it's good effort better applied to a new build at this point, since you know well the issues?

But this link shows some solutions; in case you want to poke it one last time:

http://support.mozilla.com/tiki-view_forum_thread.php?locale=th&comments_parentId=80106&forumId=1

I'm curious, if you were to build a system from scratch, what gcc and
glibc versions would you use?

I realize linuxfromscratch uses gcc-4.4.1 and glibc-2.10.1 but that does
not mean it is recomended as the most stable.

What would you use and why, or what do you use and why?

nathan

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