automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "error while loading shared libraries: foo.so.0: cannot open shared


From: Ralf Wildenhues
Subject: Re: "error while loading shared libraries: foo.so.0: cannot open shared object file: No such file or directory"
Date: Wed, 9 Jan 2008 21:40:34 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

[ http://thread.gmane.org/gmane.comp.gnu.libtool.general/8726 ]

Hello Laurence,

Apologies for the delay, and apologies again for not citing better,
and thanks for the report.  There are two slightly differents
setups, as far as Libtool is concerned.  For the first one I can
confirm your issue, but the second I think is different.

- Either /usr/local/lib is listed in /etc/ld.so.conf
  and then the configure script should find that out and cause
  /usr/local/lib to be listed in
    ./libtool --config | grep "^sys_lib_dlsearch_path_spec="

- or /usr/local/lib should not be listed in /etc/ld.so.conf
  and then it may not either show up in
    ./libtool --config | grep "^sys_lib_dlsearch_path_spec="

  If it does, then that's a separate bug that we should look at.


The second setup will cause libtool to add 

  -Wl,-rpath -Wl,/usr/local/lib

to the link of the program, which will cause it to find its library.

So in the following let's deal with the first setup only.
And of course only GNU/Linux.

FWIW, here's a script to reproduce the error.  You may have to adjust it
for your use, and you should use it carefully as it modifies root-owned
files.

--- snip ---
#! /bin/sh

: ${SUDO="su -c"}  # adjust this as needed.

set -e  # error out on nonzero command.

cat >configure.ac <<'END'
AC_INIT([ldconfig-bug], [1], [devnull])
AM_INIT_AUTOMAKE([foreign])
AC_PROG_CC
AC_PROG_LIBTOOL
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
END
cat >Makefile.am <<'END'
lib_LTLIBRARIES = libfoo.la
bin_PROGRAMS = foo
foo_LDADD = libfoo.la
END
cat >foo.c <<'END'
extern int foo ();
int main () { return foo (); }
END
echo 'int foo () { return 0; }' > libfoo.c

libtoolize -c
autoreconf -vi
./configure
make

# ensure /usr/local/lib is not searched by default:
grep /usr/local/lib /etc/ld.so.conf /etc/ld.so.conf.d/* && exit 1
$SUDO ldconfig

# ensure libfoo.so is not found by default:
.libs/foo && exit 1

# install.  This will cause `ldconfig -n /usr/local/lib' to be run:
$SUDO 'make install'

# try running.  This will fail:
/usr/local/bin/foo
--- snip ---


So, what's the meat of the problem:
- libtool calls 'ldconfig -n $libdir'
- 'ldconfig -n' implies '-N' which means not to update the cache
  (so all it does is add symlinks if needed; which should not be
  needed due to libtool having done that work)
- ld.so however does not search all dirs in /etc/ld.so.conf.
  What it does is search
    -- dirs specified in LD_LIBRARY_PATH
    -- candidate files from /etc/ld.so.cache
       (which has not been updated yet)
    -- /usr/lib and /lib

Strictly speaking, I guess libtool should call plain ldconfig.
*That* however could be unbearably slow if done for every library
being installed.  One cool thing would be if ldconfig had a mode to
update the cache but by reading only one directory, as BSD ldconfig
does.

Sigh.

Cheers,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]