Re: SOLVED: unable to launch app due to "cannot open shared object file"

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

 



Tom Poe wrote:
Tony Nelson wrote:
At 8:23 PM -0500 5/19/07, Tom Poe wrote:
Tony Nelson wrote:
At 8:01 PM -0500 5/19/07, Tom Poe wrote:

Tony Nelson wrote:

At 5:02 PM -0700 5/19/07, stan wrote:


On Sat, 19 May 2007 16:56:56 -0500
Tom Poe <tompoe@xxxxxxxx> wrote:



$ openmovieeditor: error while loading shared libraries:
libgavl.so.0: cannot open shared object file: No such file or
directory

[1]+  Exit 127                openmovieeditor

I then ran:
$ locate libgavl.so
/home/tom/temp/gavl-0.2.5/gavl/.libs/libgavl.so
/home/tom/temp/gavl-0.2.5/gavl/.libs/libgavl.so.0
/home/tom/temp/gavl-0.2.5/gavl/.libs/libgavl.so.0.0.0
/usr/local/lib/libgavl.so
/usr/local/lib/libgavl.so.0
/usr/local/lib/libgavl.so.0.0.0

I then brought up /etc/ld.so.conf and added
"include /usr/local/lib/", then I ran command: ldconfig
but no go.  Any solutions?
Tom


This might be a long shot, but I'm thinking that it is a dependency
that libgavi.so.0 needs that is causing the problem. i.e. it is trying
to call another library and it isn't there.  Not sure how you would
verify that, unless it is in the logs somewhere, or you install the
libgavi-devel package so you can then run gdb on the process to find
out where it is failing.


My own guess is that libgavl's home in /usr/local/lib/ is not in the
default library search path in /etc/ld.so.conf and /etc/ld.so.conf.d/. ldconfig -p | grep '/usr/local' will probably be empty. Google around a
bit before making too much of this; I've never done it myself.


Well, everyone was helpful.  Turned out that when I ran "echo
LD_LIBRARY_PATH" it was empty.  I added /usr/local/lib by typing (I
think):  ]$ LD_LIBRARY_PATH=/usr/local/lib and then:
export LD_LIBRARY_PATH

That should do it, at least until I have to shut down and boot up
again.  :)
Tom

Google on "linux library search path" to find out why LD_LIBRARY_PATH isn't
such a good idea.

I'm afraid to look.  :)
What's a better alternative?

AIUI, either putting the lib in a standard location (/usr/lib) or adding a
file to /etc/ld.so.conf.d/ and then running ldconfig (man ldconfig).  The
suggestion was that LD_LIBRARY_PATH affects all uses of shared libs and
that can have unintended consequences.  Perhaps /usr/local/lib is safe
enough.
RATS! At one point, I came across something on google, and entered a line in /etc/ld.so.conf, not ld.so.conf.d, then ran ldconfig. It didn't work, of course.
Tom


Run ldd against the executable, it will tell you where it thinks your library should be. Once you've found that double check where the library actually is. If it isn't where the executable thinks it should be make sure the package that contains the library is an up to date version, and if so if that version is correct for the version of executable you are running. If all looks well and your lib is still in the wrong place then symlink it.


- Tod


[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux