Ldd shows library exists and is linked, program doesn’t find it

dynamic-linkinglibrariessudo

Console Output:

bitnami@linux:~$ sudo svnmucc propset svn:needs-lock 1 file:///opt/bitnami/repositories/Standard/Ipc/trunk -m "test set"
svnmucc: error while loading shared libraries: libsvn_client-1.so.0: cannot open shared object file: No such file or directory
bitnami@linux:~$ ldd /opt/bitnami/subversion/bin/svnmucc
        linux-vdso.so.1 =>  (0x00007ffee8dfc000)
        libsvn_client-1.so.0 => /opt/bitnami/subversion/lib/libsvn_client-1.so.0 (0x00007f3d66102000)
        libsvn_wc-1.so.0 => /opt/bitnami/subversion/lib/libsvn_wc-1.so.0 (0x00007f3d65e30000)
        libsvn_ra-1.so.0 => /opt/bitnami/subversion/lib/libsvn_ra-1.so.0 (0x00007f3d65c22000)
        libsvn_diff-1.so.0 => /opt/bitnami/subversion/lib/libsvn_diff-1.so.0 (0x00007f3d65a09000)

I tried:

"No such file or directory" on an executable, yet file exists and ldd reports all libraries present

I installed:

lib32z1, lib32ncurses5, lib32bz2-1.0

I set:

LD_LIBRARY_PATH="/opt/bitnami/subversion/lib:/opt/bitnami/sqlite/lib:/opt/bitnami/apache2/lib:/opt/bitnami/common/lib"

I am on a –

linux 3.13.0-55-generic #94-Ubuntu x86_64 GNU/Linux

– Bitnami SVN stack. So it is very likely that the Bitnami guys might have cranked something up. Fresh Debian/Arch/Ubuntu is not a solution (Company doesn't want something they can't pay for)

Q: How do I get further? It should have a 64bit 'lib-loader' installed since I am on a 64bit System. svnmucc is further provided by SVN itself, so it should have all libs necessary installed. I would figure that Bitnami somewhat tempered with the System, and now it doesn't have access to it (or something similar). Yet I haven't dealt much with libraries, which is why I am not very well funded in that topic.

Best Answer

LD_LIBRARY_PATH settings are dropped by sudo for the security. To avoid being affected by that, you could add those paths to dynamic loader's global search path list.

Put the library path lines in /etc/ld.so.conf.d/bitnami.conf:

/opt/bitnami/common/lib
/opt/bitnami/apache2/lib
/opt/bitnami/sqlite/lib
/opt/bitnami/subversion/lib

Then update /etc/ld.so.cache by the folowing command:

sudo ldconfig

See ld.so and ldconfig manuals for details.

Related Solutions

Ubuntu – Finding the library versions a library was linked against

Maybe

 readelf -a

It displays information about ELF files. If the object you are studying still contains the comment section, you may try to extract it by

 readelf -p .comment yourfile

For example

$ cat test.c
int main () {
  return 0;
}
$ gcc test.c
$ readelf -p .comment a.out

String dump of section '.comment':
  [     0]  GCC: (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1

objdump could provide the same information.

If the comment section is stripped, you may try to read the GCC runtime symbol version info from the readelf -a command if it is a c++ compiled library. Note, that is the version of symbols supplied to the compiler and not necessarily the version of the compiler. I don't know how useful that would be to track down the Ubuntu version.

ldd Equivalent – Fail When Library Not Found

Take care with ldd on linux; it's just a bash script which, at least on older systems, will run the given program with LD_TRACE_LOADED_OBJECTS=1 in its environment.

This means that if the program has other interpreter than /lib{64,32}/ld-*, that program will be run with your target as its first argument, even if you didn't mean to do it. If you run ldd on an executable owned by some other user, that user will own you instead.

You can check what interpreter is defined in the ELF headers with readelf -l "$target" | grep interpreter.

On newer systems, ldd has been changed to pass the target as argument to an interpreter taken from a list of 'good' interpreters (eg. /lib64/ld-linux.so.2 target); I don't find that convincing, but it's up to you to make the determination if that's safe enough.

If you find all that acceptable, the simplest way to do it is:

if ldd "$target" | grep -q 'not found'; then
   echo >&2 "$target is missing dependencies"
   exit 1
fi

If called in 'trace mode' (as from ldd), the default dynamic loader on linux will always exit with a 0 status, and there's no way to change that via command line switches or environment variables; you'll have to change its source code.

Best Answer

Related Solutions

Ubuntu – Finding the library versions a library was linked against

ldd Equivalent – Fail When Library Not Found

Related Question