linking against shared libraries (2) - Unix

This is a discussion on linking against shared libraries (2) - Unix ; Greetings! On Solaris 9 sparc, a binary is compiled with gcc 3.4.2: % ldd blib/arch/auto/Image/Magick/Magick.so | grep jpeg libjpeg.so.62 => (file not found) libjpeg.so.62 => /usr/sfw/lib/libjpeg.so.62 How come the shared object is ... found and not found at the same ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: linking against shared libraries (2)

  1. linking against shared libraries (2)

    Greetings!
    On Solaris 9 sparc, a binary is compiled with gcc 3.4.2:

    % ldd blib/arch/auto/Image/Magick/Magick.so | grep jpeg
    libjpeg.so.62 => (file not found)
    libjpeg.so.62 => /usr/sfw/lib/libjpeg.so.62

    How come the shared object is ... found and not found at the same
    time? Compiled with -R/usr/sfw/lib - that's where the .so is located.


    However,
    % LD_LIBRARY_PATH=/usr/sfw/lib ldd blib/arch/auto/Image/Magick/
    Magick.so | grep jpeg
    libjpeg.so.62 => /usr/sfw/lib/libjpeg.so.62

    Here all is well and libjpeg.so.62 is only listed once.


  2. Re: linking against shared libraries (2)

    noident@my-deja.com wrote:
    > Greetings!
    > On Solaris 9 sparc, a binary is compiled with gcc 3.4.2:
    >
    > % ldd blib/arch/auto/Image/Magick/Magick.so | grep jpeg
    > libjpeg.so.62 => (file not found)
    > libjpeg.so.62 => /usr/sfw/lib/libjpeg.so.62
    >
    > How come the shared object is ... found and not found at the same
    > time? Compiled with -R/usr/sfw/lib - that's where the .so is located.
    >
    >
    > However,
    > % LD_LIBRARY_PATH=/usr/sfw/lib ldd blib/arch/auto/Image/Magick/
    > Magick.so | grep jpeg
    > libjpeg.so.62 => /usr/sfw/lib/libjpeg.so.62
    >
    > Here all is well and libjpeg.so.62 is only listed once.


    That's a good question. As a random guess, perhaps it is an issue
    of transitive dependencies. Perhaps Magick.so has an rpath ("-R"
    thing) built into it, but one of Magick.so's dependencies also
    requires libjpeg.so.62 and does not have an rpath built into it.
    So when the linker tries to resolve it for Magick.so, it consults
    Magick.so's path and finds it, but when it tries to do the same
    thing for the other shared object which Magick.so depends on and
    which depends on libjpeg.so.62, that other shared object does not
    have the rpath set to include /usr/sfw/lib, so the runtime linker
    can't find that.

    Of course, that's just random speculation, but it's the only
    explanation that springs to mind. You could possibly check
    this by listing off all the libraries that Magick.so requires,
    then checking each one of those with ldd to see if it can,
    independently of Magick.so, have its dependencies satisfied
    (while LD_LIBRARY_PATH is not set).

    - Logan

  3. Re: linking against shared libraries (2)

    > Perhaps Magick.so has an rpath ("-R"
    > thing) built into it, but one of Magick.so's dependencies also
    > requires libjpeg.so.62 and does not have an rpath built into it.


    This is exactly the case. I didn't realise ldd would try and list
    dependencies as well.
    Thanks heaps.


+ Reply to Thread