Linux linking and dependencies

JonB

I need a Linux dynamic linking guru, please!

I am in the process of moving my environment over to Ubuntu 20.04. I have an existing executable (nothing to do with Qt). All you need to know is that it was linked with

gcc -m64 -o forth forth.o external.o  -lreadline

If I do an ldd on the executable file

	linux-vdso.so.1 (0x00007fff94b5d000)
	libreadline.so.7 => not found
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd9f0b5f000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fd9f0f7e000)

I have done my apt-get install libreadline-dev. At 20.04 this has created

/usr/lib/x86_64-linux-gnu/libreadline.a
/usr/lib/x86_64-linux-gnu/libreadline.so
/usr/lib/x86_64-linux-gnu/libreadline.so.8
/usr/lib/x86_64-linux-gnu/libreadline.so.8.0

So libreadline has moved from 7 to 8. My program will not run

error while loading shared libraries: libreadline.so.7: cannot open shared object file: No such file or directory

My question: I thought the whole point was if I linked an old executable against libreadline.so.7, which happened to be the current one at the time, it would now happily run against a later version, such as libreadline.so.8, at run-time? Else you'd have to keep re-compiling/linking sources for each future OS upgrade. Or, the Linux Admin has to start creating soft links from 8 to 7, if that even works.

?

JonB

@sierdzio
Blimey, yes, that's a bit to read that I am unfamiliar with! I will do so if I want to go down that route, thank you.

As the second reply there states, the fact that Ubuntu is now at libreadline.so.8 implies that it will not be binary compatible with expectations for libreadline.so.7. The change in version number tends to indicate this. That is fair enough.

But then I am equally "surprised" that when I look Ubuntu 20.04 only offers an apt-get install ... choice of libreadline8 or libreadline5. No libreadline7.

Anyway, I have just spoken to a Linux Admin friend, and he says he's not keen on version-independent linking, as the app may indeed fail to work with a newer version. He says he would expect either

Go find the correct old version in an older Ubuntu, and get that.
Or, recompile & relink against what's available now. Which is what I will do, when I have the time.

So @sierdzio thanks for your answer, it's useful to know about the version-independent, but I am going to mark this as my correct solution.

sierdzio

If libreadline 7 and 8 are binary compatible, you can create a symbolic link for it:

sudo ln -s /usr/lib/x86_64-linux-gnu/libreadline.so.8 /usr/lib/x86_64-linux-gnu/libreadline.so.7

My question: I thought the whole point was if I linked an old executable against libreadline.so.7, which happened to be the current one at the time, it would now happily run against a later version, such as libreadline.so.8, at run-time?

Yes, but the trick is to link against the unversioned library file libreadline.so, not libreadline.so.7.

JonB

@sierdzio

If libreadline 7 and 8 are binary compatible, you can create a symbolic link for it:

Indeed, that's what I wrote. But it is "unacceptable" for the Linux Administrator to have to make a system change like this in order for an older executable to run, I am looking for a solution which does not require system changes.

Yes, but the trick is to link against the unversioned library file libreadline.so, not libreadline.so.7.

I could not agree more! That's why I showed my link line was

gcc -m64 -o forth forth.o external.o  -lreadline

What I expected/hoped from you is instruction as to what it should have been to make it un-versioned!?

sierdzio

This post seems to have the correct answer for you: https://stackoverflow.com/questions/4685493/gcc-linking-to-a-shared-objects-linker-name

You'll need to relink the app on your previous machine.

JonB

@sierdzio
Blimey, yes, that's a bit to read that I am unfamiliar with! I will do so if I want to go down that route, thank you.

As the second reply there states, the fact that Ubuntu is now at libreadline.so.8 implies that it will not be binary compatible with expectations for libreadline.so.7. The change in version number tends to indicate this. That is fair enough.

But then I am equally "surprised" that when I look Ubuntu 20.04 only offers an apt-get install ... choice of libreadline8 or libreadline5. No libreadline7.

Anyway, I have just spoken to a Linux Admin friend, and he says he's not keen on version-independent linking, as the app may indeed fail to work with a newer version. He says he would expect either

Go find the correct old version in an older Ubuntu, and get that.
Or, recompile & relink against what's available now. Which is what I will do, when I have the time.

So @sierdzio thanks for your answer, it's useful to know about the version-independent, but I am going to mark this as my correct solution.