-1

I want to upgrade my current running applications to latest version. But due to some package issue i am unable to install them.

I get common error in that: /usr/lib64/libstdc++.so.6: version 'GLIBCXX_3.4.15' not found.
When i tried to update glibc package i get following output: 

[root@agastya ~]# yum install glibc
Loaded plugins: refresh-packagekit, rhnplugin
epel/metalink | 3.8 kB 00:00 
epel | 4.3 kB 00:00 
epel/primary_db | 5.0 MB 01:33 
epel-testing/metalink | 3.8 kB 00:00 
epel-testing | 4.3 kB 00:00 
epel-testing/primary_db | 295 kB 00:03 
rhel-x86_64-server-6 | 1.8 kB 00:00 
rhel-x86_64-server-6/primary | 11 MB 02:02 
rhel-x86_64-server-6 8816/8816
Setting up Install Process Package glibc-2.12-1.80.el6_3.6.x86_64 already installed and latest version Nothing to do 
[root@agastya ~]#

Should i need to add some more repositories?
If yes, how?

Aliaksandr Belik
  • 259
  • 6
  • 17
TPS
  • 55
  • 1
  • 1
  • 8

3 Answers3

2

glibc-2.12-1.80.el6_3.6 is the latest updated package for glibc in RHEL6. I am certain that a package like glibc will not be rebased to v3. If you are doing this on a production RHEL server, the simple rule is don't, don't do it.

For testing purpose, feel free to add the fedora repo or rpmforge or whatever gives you the latest one. But, I am quite sure you will face hell lot of dependency problems and worst case, system might break.

Soham Chakraborty
  • 3,534
  • 16
  • 24
  • Thank you Soham, that's fine. I am ready to take risk on this, but I am not able to find the correct repo for the same. – TPS Jan 28 '13 at 11:10
0

There's no newer version of core RHEL components available (GLIBC, kernel, etc.). This is how RHEL/CentOS works.

See: In CentOS 6.x, how can I upgrade to Kernel 3.4? or Newer GLIBC for RHEL/CentOS 5.x

You probably won't find the libraries, etc. that you need without switching to another distribution of Linux or heavily modifying your RHEL installation. Fedora may be a better choice in this case.

Community
  • 1
ewwhite
  • 194,921
  • 91
  • 434
  • 799
-3

I have updated the antiquated libstdc++.so6 because i was nerved that is was impossible to install actual software, every time the linker was complaining about that it didn´t find the GLIBCXX_3.4.15. gcc 4.8.1 comes with the gcc 4.8.1 sources and the actual libstdc++.so.6. I build gcc 4.8.1 and installed it. Then i made a symbolic link:

/usr/lib/libstdc++.so.6 -> /usr/lib/libstdc++.so.6.0.13

to ensure that all depending applications would find "their" libstdc++.so.6. I secured this with the "alternatives" command, but i am quite certain that this is not mandatory. Only java was complaining about the libstdc++.so.6, but since java (jre-1.7.0) is not in my main focus i switched java back to jre-1.6.0. (I don´t know if i am willing to invest more time in java.)

I know, i know, every fundamental CentOs prayer would like to lapidate me for that, but i am bored in using old software only for idealistic reasons of others. Maybe this has a drawback, but someone should explain where the drawback is when using a newer libstdc.so.6. while i am working without flaws with this solution. I would claim, there is no drawback. The yum packet manager seems to function in a normal way and if there should be a problem, i would try to fix this as well, but there is no problem (until now). Off course, one should have a functional backup system/strategy and a fallback insurance and he/she should now, what to do and what they are doing.

This solution works for me, don´t know, if this is a solution for others.

regards

Coliban
  • 101
  • 3