[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: "error while loading shared libraries: foo.so.0: cannot open shared
Re: "error while loading shared libraries: foo.so.0: cannot open shared object file: No such file or directory"
Sun, 16 Dec 2007 21:42:09 -0600 (CST)
On Mon, 17 Dec 2007, Laurence Darby wrote:
Your email seems to contain a lot of details, but upon closer
inspection the details are not of the right type. For example, you
have not even identified the operating system you are using.
Sorry, it's i686-pc-linux-gnu, Slackware 12.0 (mostly).
Thanks for this info. It definitely can make a difference when
locating the cause of a problem.
I thought it did, but this isn't a linking problem (as in /usr/bin/ld).
The problem is loading a program at start up time (when loading dynamic
It's only when a package builds its own libs which it dynamic links to
runtime, which isn't that rare.
Without actually downloading and inspecting your package, I think that
the problem you are running into is probably due to not specifying the
dependency library using the correct syntax. When the program is
built, I see
/bin/sh ../libtool --tag=CC --mode=link gcc -std=c99
Note the -L../libinotifytools/src. The -L syntax is best left for
libraries which are already installed. Instead you should be using an
LDADD statement for your program. The correct syntax is something
inotifywait_LDADD = ../libinotifytools/src/libinotifytools.la
Automake and libtool should then do the right thing so that your
program can be executed from the source tree, as well as when formally
installed. Since it now knows that the library is built by your
package, it can re-link the executable, run ldconfig, or do whatever
else is necessary to get the installed program running properly.
Since -rpath was specified when the library is built, I suspect that
the program will be relinked with the library during the install step.
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/