glibc upgrade - how to ?

[Vijaya Kumar_3]

Hi
I am facing some native threads issue with my linux server with Weblogic. It seems to be it is running out of native threads...

My Configuration
Redhat Linux 8.0 with 4 processors and 4GB RAM
Kernel 2.4.18
Glibc 2.2.93

I need to upgrade glibc to 2.3.2, is there a way to do it easily?

guide me thanks

TIA
Vijay

[K.C. Chan · Accepted solution]

AFAIK, I have attempted it before but there are applications (RPMs) which depends on this. I ended up installing a compatible glib to get around this.

[Steven E. Protter]

http://www.redhat.com

Download

Rpm section

search glibc

Find and download your version number

rpm -i name_of_file

Its installed.

SEP

[Steven E. Protter]

Ah,

You are going to have to respond to all the dependency messages, obtain the rpm files and do the isntallation.

This could get very complex, much less complex than say an upgrade to Red Hat 9.

SEP

[Vijaya Kumar_3]

Thanks for your reply. Sorry for the late.

Chan:

Can u tell me how did u replace the libraries...Thanks

Steven:

I know your way is too complex. I need a easy solution

Thanks anyway
Vijay

[Stuart Browne]

Actually, I'd have to agree that SEP's is the easier way to go.

Compiling a glibc is ok. Implementing it is dangerous, 'cause one typo, and you're going through even more complicated recovery proecures (or even rebuilding the machine).

I've done this once or twice on old systems. It's much easier just to upgrade.

[Vijaya Kumar_3]

Thanks Stuart.

Steven,
I am not sure about upgrading all RPMs...
can u pls tell me.. i am little bit confused..

Thanks
Vijay

[Vijaya Kumar_3]

btw,
i am not ready to upgrade to RHL9.0

Thanks

[Martin P.J. Zinser]

Well, one supported and relatively easy way to get all the dependencies right is to upgrade the OS (this is actually one of the reasons why the various distros are around in the first place). You would need to check with RH if Version 9 is up to glibc 2.3.2 or higher.

[Stuart Browne]

If you are willing to compile your own, then I guess you could go down this path.

wget ftp://mirror.aarnet.edu.au/pub/redhat/linux/updates/9/en/os/SRPMS/glibc-2.3.2-27.9.src.rpm
(or from your local mirror)

rpmbuild --rebuild glibc-2.3.2-27.9.src.rpm
(this will take a *LONG* time)

Then forcibly install the resultant RPMS (/usr/src/redhat/RPMS//), possibly using a '--nodeps' flag.

As to what issues this will cause you for 'future' rpm installations, I couldn't say.

[Stuart Browne]

Just did a quick attempt here.. ANd to do what I said int he previous post, you'll need to update a number of packages (GCC, binutils to start with) using a similar method to begin with..

So probably not too easy.

[Vijaya Kumar_3]

I agree with u stuart...
what about downloading glibc source and compiling ...

I will do a modification to Load library path for new libraries... does that work

-Vijay

[Vijaya Kumar_3]

i mean in a seperate directory

with a --prefix=/root/myglibc

[Stuart Browne]

Never tried it so can't advise.

But start by downloading the source, reading through the requirements.

It may be tha tyou need to update those utilities anyway in order for the new glibc to even build properly.

[Vijaya Kumar_3]

Let me try that tomorrow and post it later...

Thanks stuart...

Vijay

[Steven E. Protter]

I'm seeing some complicated information in this thread.

I'd say you can go with the source code. I'm still not sure that will get you around the dependency issue.

I'd say you can go source code, or rpm, responding to each dependency message with a download. There is the upgrade route. I know of valid reasons why you would not want to upgrade the OS.

Another idea comes to mind.

Download the rpm and then use the GUI gnome installer to do the install. It might be good enough in that distribution to list the dependencies and you can build a little rpm depot with everything you need for the upgrade.

Its worth a shot.

SEP

[Stuart Browne]

I think that no matter which direction you go, it will be dependancy-tree hell.

It's the core componant of a modern linux system. It need lots of stuff, and is used by basically *EVERYTHING*..

Thus why updating it sucks :P

[Vijaya Kumar_3]

I agree.

Let me see what i can do for it...

Thanks guys for ur suggestions

-Vijay

[Martin P.J. Zinser]

Hi Vijay,

one more point here. What you intend to do really has the potential to mess up your system royally (no offense to the Kings ,-). So the very least you should do before going down this road is to make sure you do have a good, complete, working backup of your system, so you do have a place to return to in case things go bad.

Greetings, Martin

[Mark Grant]

I'm with Martin on this one. I have been in the Linux world a long time and I just would not do this. It's not worth it. Even if you succeed, you will come across problems long down the road.

My way would be to make a new partition (re-arrange existing partitions if necessary) and install a new limited Linux in it. Then mount any filesystems you need from the old linux and use the same swap partition.

This is a good general practice any way, that way you can always install new linux distributions and have a regression path.

[K.C. Chan]

compiling it and putting it a different location is a good idea. But there is an option for rpm which you can tell it where to intsall. I had used it once on my laptop running rh9 trying to install enlightenment and their was a depenency on some lib which I could not get around becase the default desktops and some other apps (couldn't remember) needed it. I ened up using the relocate option and it works great. I think the relocate option is similar to compiling the source and putting it in a different path. You may want to try this first. Here's what I did to determine which path it will used; rpm -qpl , this should give a listing of files (full path) in the package which you will need for relocate options.

BTW, I used a lower glibc for the compatible lib. I am not sure if there is a compatible glibc for higher glibc version. I believe a compatible glibc is just another lib which can be install on a different path; So whether you compile and specify a different path to be installed, use a compatible glib, or use the relocate option, the end result is the same. You get to install your glibc of choice.

Since glibc is tied into so many aspects of the systems and apps, I totally advocate that you have a decent back up which you can recovers from this or try it on a test box first.

[Umapathy S]

Vijay,
RPM update is the best way to do it. I have nearly dumped/reinstalled the whole systems in the past when doing this type of experiments on my desktop.

When you are rebooting the machine with the paths (LIBPATH, LD_LIBRARY_PATH) all oriented towards the new dir, you may end up with some other broken links, dependency hell (a very good term).

HTH,
Umapathy

[Martin P.J. Zinser]

Hi Vijay,

in case you want to experiment with this glibc
upgrade, it might be useful to check the documentation of the Linux from scratch project

http://www.linuxfromscratch.org/

since this should shed some light on the various dependencies you are likely to encounter. Incidentally their latest document does cover exactly the glibc version you have as your target

Greetings, Martin