For one particular program I need to use old versions of object (.so) files. So for instance, I need to use libc-2.3.4.so instead of libc-2.5.so . The .so files appear to all live in /lib . I want to change the path for picking up these files. How do I do this?

i.e. I imagine I want to do something analagous to setting PATH or PYTHONPATH, like:

export FOO=/lib/oldstuff:/lib

But what is FOO?

(.so) files are shared library files and the extension donates the "soname", for those to be needed at the runtime you have to set the $LD_LIBRARY_PATH and not $PATH:
something like this could help you:

Again the path a shared library uses depends upon the nature of their use. Most of the library files resides on /usr/lib/, the libraries needed at startup are in /lib/ and those are not part of the system are in /usr/local/lib.

1 members found this post helpful.

you can edit the autotools files in the source
the macros or the configure.in or configure.am
or
if it is a makefile project edit the makefile

update the program to use a current version of that lib

or
the old "fudging it " hack
link libc-2.5.so to libc-2.3.4.so
but it is likely that 2 versions is WAY too different
-- so this is NOT expected to work --
I would update and rewrite the source code to use a modern version of libc

@JohnVV:
Would there be any possibility the OP can make an entry with their library path in /etc/ld.so.conf.d/some_file.conf and run /sbin/ldconfig for the changes to take effect. this could be alternate and good solution for OP's issue. isn't it?
I am asking as I have not tried it and currently away from my system to test it.

SAbhi, I know nothing about ldconfig, but I can see some /etc/ld.so.conf.d/*.conf files on my system. Each line in the files is a lib directory, so it looks like they specify a search path, is that correct? It does sound a lot like what I want.

JohnVV: rewriting the source code is not an option. It is a commercial package, only supported on certain Linux distributions. Naturally our newest and fastest machine does not run one of them. (And before you tell me to reboot it with an older distribution, we have other commerical software which only runs on the newer Linux distributions). The errors occur at run time.

Correct that's what they do afaik, Anyways you can try doing either of what I suggested that will serve the purpose.


I think John said: he will update the source code to remove the dependency of older version of libc package, well that's a good.

well if this is proprietary code
then they INSTRUCTED you to use the operating system it was desinged for
from "libc-2.3.4" that would be RHEL4

CentOS 4.9 is DEAD !!!!!
RHEL 4.9 is on "extra extended life support" ( for just over one more year )

BUY it!!!!
RHEL 4.9
and install this program on the OS is was made for


the ONLY version of RHEL4 that is still supported IS RED HATS !!!
and you need to buy the required support contract for it !

JohnVV: running RHEL 4.x is not an option. The machine is running Centos 5.8 and we need Centos 5.x to run program Y. But we also want to run program X which is supported only up to Centos 4.x.

Here is what I've discovered:

1. If I remove /lib/*.so*, and replace it with all the /lib/*.so* from a Centos 4.x machine, program X runs. That's heartening, that means it is possible to run X on a Centos 5 machine.

2. However, if I instead restore all the original (Centos 5.8) /lib/*.so*, and put the centos 4 versions in a directory called /lib/lib_centos4; and then:
then X does not run. So that means that altering LD_LIBRARY_PATH does not work.

I've tried looking at ldconfig but you've got to be superuser.

What I want is some way to adjust the lib paths only when running program X. Even if I have to create a subprocess. It appears there are tools to do this if your program is in ELF format, but X is not in ELF format. (I've established this by running readelf). Any other suggestions?

i take it you are aware that CentOS 5.8 is unsupported and has NOT received security updates since Jan 1 2013 - and never will .
CentOS 5.9 is the only supported version of the older 5 series

grab an old copy of rhel/Cent 4.9 and install it on a VM in centos 5 ( please UPGRADE to the only supported version ! 5.9 )

it is VERY unlikely you will be able to get a rhel4 program running and working on rhel5


an analogy
it would be like getting a windows 95 program running on xp ( but with NO 16 bit support)




well if you really want to try coping the libc from Cent4 onto cent5
you might be coping more than 75% of the cent4 OS

just write a startup shell script that exports the location of the centos 4 libs

but be very careful if centos5 can see them and tries to use them
you might kill the install ( as in it might not even boot )

1 members found this post helpful.

But I did! As I've explained above, when I replace all the *.so* files in /lib with centos 4.6 copies (previously I incorrectly said 4.8), it worked. (i.e. program X, which runs on centos 4.x, ran on a machine running centos 5.8). Though I see now that was a dangerous thing to do. (i.e. what if the bash shell needed one of those files when I was in the middle of moving them??) But it did prove that the centos 5.8 machine could run program X. I've now restored the correct (centos 5.8) *.so* files back in /lib .

From some more searching it does look like LD_LIBRARY_PATH is the right thing to be adjusting and I think I'm just setting it wrong. But here's the curious thing: when I first start a shell on this machine (or any of our linux machines), LD_LIBRARY_PATH is not defined. Should it be? What is the library search path if LD_LIBRARY_PATH is not defined?

I've taken on board your comments about support for 5.9, but that's a lower priority.

I have no idea if this will work

as root

Code:

cat > /etc/ld.so.conf.d/lib_centos4.conf << "EOF"
/lib_centos4
EOF

now place your libs in /lib_centos4
and run ldconfig as root

^^ Overkill

if that fails, what does your application do?
any reason you can't run in a VM?

1 members found this post helpful.

Your suggestion is similar to what I've tried, except for the .conf file. I'm not sure what that changes but I'll give it a go.

It runs a set of checks on an engineering design. So it's a non interactive run, which might take minutes or hours, depending on the size of the design. It runs on a networked machine. The point being, we want any engineer in the office to have access to our fastest machine when they need it, so they can check their design as fast as possible.

As for a VM, you mean with VMWare or similar? I guess it's possible but it sounds like overkill. My limited experience with VMware is it's not always easy to set up. And wouldn't I have to divide up the machine's resources? The whole point is we want our fastest and biggest machine to devote all its resources to any run, whether it's tool X (which uses centos 4.x) or Y (which uses centos 5 or greater).

It might cause problems, and it is overkill
it will map all the CentOS4 .so files and could cause some strange behaviour
you would be best dropping things in one by one

To prevent the potential boot failure, you could employ a simple bind mount so those libs are not available during boot, at least until you are happy it is safe.

paid for?
have you asked for support on it?
I understand
Yes
VM may limit you with regards to resources, but at the moment you have a 100% limitation in that you can't do what you want to do
If a VM solves that you are 100% better off.

Try a VM, you might find the resource issue is negligible, and it is much preferred to risking the stability of a production system.

1 members found this post helpful.

We stopped paying support but are allowed to continue to use the old version. Sometimes that's the reality of being a small company in a world of expensive software :-/

ETA: I imagine the VM would also create an extra level of hassle for users connecting to the machine. (Remember it's networked, and we also want the "real" machine in Centos 5 to run our newer software which I've called Y). For that and other reasons I've already mentioned, I'd like the VM to be a last resort.

hmm

a VM is a perfect fit for what you want
OK there is _some_ overhead , but I think that is going to be negligible. I imagine most of the time it will be sitting idle.

Your users will 'network' to the VM like it was any other box, so no issue there.

For a 'look see' try VirtualBox, it is very easy to setup
install CentOS 4.x with the bare minimum for your application
run the VM 'headless' once you have it all setup and running.