I have several builds of an application on my system (a dev build and many older released builds). When I'm trying to run an older release, the system invariably picks up the dynamic libraries from the dev build.

From /home/franz/Projects/appleseed/archives/releases/1.1.0-alpha-14-0-g4e46ed9/appleseed/bin which is the directory of the older release I'm trying to run:

$ ldd appleseed.studio 
    [stuff omitted]
libappleseed.so => /home/franz/Projects/appleseed/build/linux-gcc4/appleseed/libappleseed.so (0x00007fbcb090b000)
libappleseed.shared.so => /home/franz/Projects/appleseed/build/linux-gcc4/appleseed.shared/libappleseed.shared.so (0x00007fbcb030c000)
    [more stuff omitted]

(/home/franz/Projects/appleseed/build/linux-gcc4/appleseed/ is the path to my dev build.)

Naturally I should set LD_LIBRARY_PATH correctly before running an older release:

$ export LD_LIBRARY_PATH=/home/franz/Projects/appleseed/archives/releases/1.1.0-alpha-14-0-g4e46ed9/appleseed/bin ; ./appleseed.studio

(LD_LIBRARY_PATH is initially empty so I don't bother with concatenation.)

However this doesn't work and the system continues to pick up the dev build of the dynamic libraries.

Am I doing something wrong? Any idea?

I am running a 64-bit build of Ubuntu 10.10 Maverick Meerkat (unsupported as of April 2012).

UPDATE: I have updated my system to Ubuntu 11.10 (Natty) and the problem persists.

  • What does file .../libappleseed.so output? Maybe you are trying to use an old 32-bit library with your new 64-bt binary. – Lekensteyn Sep 13 '12 at 11:10
  • Everything is 64-bit: $ file ./libappleseed.so returns ./libappleseed.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped, while $ file /home/franz/Projects/appleseed/build/linux-gcc4/appleseed/libappleseed.so returns /home/franz/Projects/appleseed/build/linux-gcc4/appleseed/libappleseed.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped. – François Beaune Sep 13 '12 at 11:22
  • Ok, then you might want to check whether ldd still reports the other paths with LD_LIBRARY_PATH=/home/franz/Projects/appleseed/archives/releases/1.1.0-alpha-14-0-g4e46ed9/appleseed/bin ldd ./appleseed.studio – Lekensteyn Sep 13 '12 at 20:25
  • Unfortunately, it doesn't: LD_LIBRARY_PATH=/home/franz/Projects/appleseed/archives/releases/1.1.0-alpha-14‌​-0-g4e46ed9/appleseed/bin ldd ./appleseed.studio returns libappleseed.so => /home/franz/Projects/appleseed/build/linux-gcc4/appleseed/libappleseed.so (0x00007fc27cce5000). I am at loss here. It looks like the LD_LIBRARY_PATH mechanism is somehow disabled on my system. – François Beaune Sep 14 '12 at 9:20
  1. Make sure that under


    you really have the shared libraries you want to load. Are they really in the bin/ directory of the archive? Not lib/?

  2. Try

    /lib/ld-linux.so.2 --library-path /home/franz/Projects/appleseed/archives/releases/1.1.0-alpha-14-0-g4e46ed9/appleseed/bin ./appleseed.studio

    You can use the options from that program to control and debug the library loading process.

  • Absolutely, the bin/ directory does contain the shared libraries I want to load. Is /lib/ld-linux.so.2 supposed to be an executable binary? I haven't got it in my system. – François Beaune Sep 13 '12 at 11:56
  • OK, it seems to be Linux's dynamic linker: kernel.org/doc/man-pages/online/pages/man8/ld.so.8.html. Seems like I should be able to install it via the package manager. – François Beaune Sep 13 '12 at 12:04
  • Can't seem to find ld-linux-so.2, ld-linux.so or ld.so in the package list or via apt-get. – François Beaune Sep 13 '12 at 12:08
  • The dynamic linker seems to be called ld-linux-x86-64.so.2 on my system. So if I run the command you suggested, appleseed.studio starts but immediately complains that it isn't started from the bin/ directory of its installation. – François Beaune Sep 13 '12 at 12:32
  • 1
    Hehe, thanks for the link. I am actually the author of appleseed :) – François Beaune Sep 13 '12 at 12:40

For 64 bit, /usr/bin/ld -> x86_64-linux-gnu-ld is the loader, not the 32 bit /lib/ld-linux.so.2 -> i386-linux-gnu/ld-2.27.so. No 32 bit loader is needed for this.

The ldd command indicates that the shared libraries it uses are in .../appleseed and .../appleseed.shared. Adding a new place for the needed libraries (the .../bin) will not change this, nor pick up the libraries in .../bin. The question that remains is how the ldd is picking up these libraries if they are not in a standard location nor in the LD_LIBRARY_PATH. I would check on how the executable was linked, you could have given a full path on the necessary libraries, and not rely on just a name, needing a set of places to scan which LD_LIBRARY_PATH would provide.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.