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: Laurence Darby
Subject: Re: "error while loading shared libraries: foo.so.0: cannot open shared object file: No such file or directory"
Date: Sat, 19 Jan 2008 17:48:40 +0000

Ralf Wildenhues wrote:

> [ http://thread.gmane.org/gmane.comp.gnu.libtool.general/8726 ]
> 
> Hello Laurence,
> 

Hi Ralf, thanks for looking at this!  
I'll admit it's not very serious, another one of my nitpicks :)

> Apologies for the delay, and apologies again for not citing better,

uh? gmane is much better than mharc, which breaks threading over month
boundaries...

> 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.

Right, the second setup works, but then nearly every google result
I found is someone saying to add /usr/local/lib to /etc/ld.so.conf,
presumably for the case of replacing system libs with local versions,
or maybe the package didn't use libtool and hence no -rpath, or it was
repackaged from /usr/ to /usr/local/ or something. 

> 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 ---
[sniped]
> --- snip ---

Thanks again for the script.

> 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.

How about just a single ldconfig at the end of make install (like
an install-exec-hook), and only conditionally:

 ldd $bindir/foo | grep -i "not found" >& /dev/null && ldconfig

Is that portable?  It wouldn't call ldconfig redundantly on BSD (or
call it only on *-linux-gnu), and it would be (slightly) faster
than manually running ldconfig which is what I end up doing anyway...

Thanks,
Laurence





reply via email to

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