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

Tod tod at stthomasepc.org
Sun May 20 02:00:14 UTC 2007


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 at fngi.net> 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




More information about the fedora-list mailing list