gcc and glibc

[Lisa Kachold]

On Mon, Sep 7, 2009 at 5:55 PM, Nathan England <nathan at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.PLUG.phoenix.az.us/pipermail/plug-discuss/attachments/20090907/6e52055f/attachment.htm