am I stuck with glibc2.2.5?
From: Wiseguy (noone_at_uber.usachoice.net)
Date: 04/18/05
- Previous message: DR: "Redhat 9 install on DL380 w/SA 6i controller"
- Next in thread: R.F. Pels: "Re: am I stuck with glibc2.2.5?"
- Reply: R.F. Pels: "Re: am I stuck with glibc2.2.5?"
- Reply: Enkidu: "Re: am I stuck with glibc2.2.5?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 18 Apr 2005 12:38:26 -0500
Has anyone else discovered what a royal pain in the ass it is to
upgrade from glibc 2.2.x to 2.3.x under Suse linux?
It seems that Suse went to great lengths to make it next to impossible
to upgrade glibc by their installing components in nonstandard locations,
linking most of the system binaries with version specific objects,
and not providing a real migration from 2.2 based systems to 2.3 unless
the customer is willing to purchase a complete distro upgrade.
Like other power users I have a system that started out as a stock
suse 8.1 installation but because of my requirements I quickly ended
up with a hybrid system because I've installed and upgraded bunches
of packages directly from the GNU source on the net. At this point I
simply cannot use the suse RPM upgrade procedures because they will
corrupt my customizations.
I've tried several times to build and install glibc2.3.3 but each time
I end up with an unusable system and I then must strip out the 2.3
code and reinstall the 2.2 RPMs from the suse media.
I've noted the following problems during my attempts
1) installing 2.3.3 into a directory such as /glibc233 confuses ld.so
and the suse ld.so which is under /lib will NOT recognize the new
libc components even if I add them to the ld.so.cache
2) when I install 2.3.3 directly over top of / the new ld.so causes
system binaries to segfault and crash. This SEEMS to be any binary
that has locale support compiled in such as ls and perl
3) a really nasty difference between 2.2 and 2.3 where under 2.2 the /lib
and /usr/lib are implicitely searched by ld.so where under 2.3 they don't
seem to be searched unless explicitly in the cache...also, under 2.3
LD_LIBRARY_PATH seems to be exclusive if it exists and will ignore the
cache completely.
These are my installation options:
I erased nptl and am using the linuxthreads addon
I use US/Eastern as my /etc/localtime and I do NOT set TZ
# CFLAGS=-O3 ../glibc-2.3.3/configure --prefix=/ --includedir=/usr/include --infodir=/usr/share/info --mandir=/usr/share/man --enable-omitfp --enable-add-ons
and
# LANGUAGE=C LC_ALL=C make install
Any clues why 2.3 is so utterly incompatible with 2.2, other than suse
screwing with the default installation options so that we are tied to their
packages forever? This actually gets me rolling on another rant:
distros need to statically link system binaries instead of making them
rely on shared objects! EVERYTHING under /sbin should be statically
linked and static versions of common admin programs should be provided.
and I'd prefer not to get into a distro flame war over this...just looking
for constructive comments about how to upgrade to 2.3 without encountering
additional pain.
----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
- Previous message: DR: "Redhat 9 install on DL380 w/SA 6i controller"
- Next in thread: R.F. Pels: "Re: am I stuck with glibc2.2.5?"
- Reply: R.F. Pels: "Re: am I stuck with glibc2.2.5?"
- Reply: Enkidu: "Re: am I stuck with glibc2.2.5?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|