> 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
%20due%20to%20some%20of%20the%20shared%20libraries%20issues%20(32/64%20etc.)%0A>%20>%0A>%20>%20http://www.slamd64.com/%0A>%20>%0A>%20>%20Neither%20LFS%20or%20BLFS%20recommend%20that%20you%20try%20to%20build%20or%20upgrade%20yourself:%0A>%20>%0A>%20>%20A%20Package%20Manager%20makes%20it%20easy%20to%20upgrade%20to%20newer%20versions%20when%20they%20are%0A>%20>%20released.%20Generally%20the%20instructions%20in%20the%20LFS%20and%20BLFS%20Book%20can%20be%20used%0A>%20>%20to%0A>%20>%20upgrade%20to%20the%20newer%20versions.%20Here%20are%20some%20points%20that%20you%20should%20be%0A>%20>%20aware%0A>%20>%20of%20when%20upgrading%20packages,%20especially%20on%20a%20running%20system.%0A>%20>%0A>%20>%0A>%20>%0A>%20>%0A>%20>%20http://www.linuxfromscratch.org/blfs/downloads/6.1/blfs-book-6.1-nochunks.html%0A>%20>%0A>%20>%20I%20would%20move%20off%20your%20content%20and%20build%20a%20new%20distro%20when%20your%20glibc%20is%20no%0A>%20>%20longer%20fresh.%20%20A%20reasonable%20expectation%20for%20every%20build%20without%20package%0A>%20>%20management%20(depending%20on%20distro%20and%20production%20use)%20is%204%20years%20before%0A>%20>%20rebuild.%20%20%20If%20this%20is%20a%20production%20server,%20you%20can%20lay%20on%20a%20build%20on%0A>%20>%20replacement%20media%20to%20minimize%20downtime,%20but%20generally,%20it's%20easier%20to%0A>%20>%20build%0A>%20>%20a%20replacement,%20migrate%20over%20and%20test%20your%20daemons,%20binaries%20or%20systems,%0A>%20>%20change%20the%20IP%20address%20and%20clear%20the%20arp%20cache%20and%20switch%20over/turn%20down,%0A>%20>%20then%20rebuild%20your%20old%20system.%0A>%20>%0A>%20>%20I%20would%20not%20build%20a%20system%20from%20scratch,%20beit%20anything%20short%20of%0A>%20>%20glibc-2.3.5%0A>%20>%20and%20recommend%202.8%20(although%20that's%20just%20from%20research%20not%20recent%0A>%20>%20experience%0A>%20>%20-%20another%20will%20tell%20you%20experience%20from%20this%20list%20I%20hope?).%0A>%20>%0A>%20>%20http://www.roseindia.net/linux-distribution/LinuxFromScratch6.2%0A>%20>%0A>%20>%20Further,%20I%20would%20not%20build%20a%20system%20from%20scratch%20for%20anything%20terribly%0A>%20>%20prone%0A>%20>%20to%20fuzzing,%20or%20use%20standard%20LFS%20hardening%20techniques%20(another%20book).%0A>%20>%0A>%20>%20--%0A>%20>%20(623)239-3392%0A>%20>%20(503)754-4452%20www.obnosis.com%0A>%20>%20http://www.obnosis.com/motivatebytruth/gnu-people.jpg%0A>%20>%0A>%20%0A>%20Lisa,%0A>%20%0A>%20I%20appreciate%20the%20input.%20I%20am%20upgrading%20from%20glibc%202.7%20and%20wanted%20to%0A>%20attempt%20to%20try%20out%20the%20latest.%20I%20might%20go%20back%20to%202.7%20or%20try%202.8,%20but%20I%0A>%20wanted%20some%20input%20from%20others.%20I%20was%20also%20using%20gcc-3.4%20and%20went%20to%0A>%20gcc-4.3.%20I%20have%20always%20tried%20to%20avoid%204.3%20as%20it%20seemed%20there%20were%20so%20many%0A>%20problems,%20but%20that%20was%20because%20the%20headers%20were%20updated%20and%20a%20lot%20of%0A>%20software%20was%20never%20updated%20for%20it,%20instead%20patches%20were%20issued.%20I'm%20very%0A>%20reluctant%20to%20attempt%20to%20use%204.4...%0A>%20%0A>%20I%20just%20might%20revert%20back%20to%20everything%20previous,%20but%20since%20I%20managed%20to%0A>%20wipe%20out%20my%20entire%20home%20backup...%20other%20thread...%20I%20figure%20I%20don't%20have%0A>%20much%20to%20lose!!!%20ha%20ha%0A>%20%0A>%2010%20years%20worth%20of%20work%20shot%20in%20one%20failed%20backup%20attempt!%20argh!%0A>%20%0A>%20You%20recommend%20glibc-2.8%20?%20I%20will%20look%20into%20that.%0A>%20%0A>%20nathan%0A>%20%0A>%20%0A>%20---------------------------------------------------%0A>%20PLUG-discuss%20mailing%20list%20-%20PLUG-discuss@lists.plug.phoenix.az.us%0A>%20To%20subscribe,%20unsubscribe,%20or%20to%20change%20your%20mail%20settings:%0A>%20http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss%0A>%20%0A>%20 "Reply to this message")
(text/plain)