glibc and ld-linux conflict on CentOS 6.5

[endrebjorsvik]

I have used user-installed Spotify 0.9.4 on CentOS 6.5 x86_64 with great success for several months. Now I wanted to try 0.9.10, but after pull, configure, download, install and register, I get the following library errors:

~/.local/lib/spotify-client/spotify: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by ~/.local/lib/spotify-client/spotify)
~/.local/lib/spotify-client/spotify: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by ~/.local/lib/spotify-client/spotify)
~/.local/lib/spotify-client/spotify: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by ~/.local/lib/spotify-client/libcef.so)
~/.local/lib/spotify-client/spotify: /lib64/libc.so.6: version `GLIBC_2.15' not found (required by ~/.local/lib/spotify-client/libcef.so)
~/.local/lib/spotify-client/spotify: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by ~/.local/lib/spotify-client/libcef.so)

CentOS 6.5 uses glibc-2.12 and libstdc++-4.4.7.
So I extracted some RPMs from Fedora 18 (glibc-2.16-24.fc18.x86_64 and libstdc++-4.7.2-8.fc18.x86_64) and put the two libraries in ~/.local/lib/spotify-client/. The 'version not found' messages disappeard, but a more difficult error appeared:

~/.local/lib/spotify-client/spotify: relocation error: ~/.local/lib/spotify-client/libc.so.6: symbol _dl_starting_up, version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference

So now I wonder if this is at all possible to fix. As far as I understood from googling, replacing ld-linux is not a simple task.
Or else I will just stick to 0.9.4 until RHEL/CentOS 7 is released. :-)

[leamas]

Frankly, I have no idea. But the simple fact seems to be that CentOS 6.4 just is too old to be supported by spotify, and given it's age it's hard to blame spotify for that. Unless you have specific reasons to run 0.9.10 I think your idea to stay on 0.9.4 until CentOS 7 is here is the best option

[hexaJer]

Hi, I use centOS 6.5 at work because some workstations are on RHEL. We must remain consistent across versions.
So if there is a solution, I'm interested.