[Top][All Lists]
[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