Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

Linux linking and dependencies



  • 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.

    ?



  • @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.


  • Moderators

    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.



  • @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!?


  • Moderators

    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.



  • @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.


Log in to reply