(8.2) share lib and ldconfig problem.
bf1783 at googlemail.com
Fri Oct 28 16:49:47 UTC 2011
> 8.2 STABLE/i386
> I'm hit by something strange.
> Basically ldconfig does not take care of some libs
> in /usr/local/lib/compat/pkg
> By sample I've updated icu (via portupgrade) and libreoffice does not
> start anymore.
> $ libreoffice
> /libexec/ld-elf.so.1: Shared object "libicuuc.so.46" not found,
> required by "libsvtfi.so"
> Portgrade did a copy of the lib into /usr/local/lib/compat/pkg and run
> ldconfig. But the lib does not appear in the listing of the ldconfig
> cache :
You mean portupgrade, probably?
> # cd /usr/local/lib/compat/pkg/
> # ls -m *icu*
> libicudata.so.46*, libicudata.so.46.1*, libicui18n.so.46.1*,
> libicuio.so.46.1*, libicule.so.46.1*, libiculx.so.46.1*,
> libicutest.so.46.1*, libicutu.so.46.1*, libicuuc.so.46.1*
> # ldconfig -r | grep pkg | grep icu
> 664:-licudata.46 => /usr/local/lib/compat/pkg/libicudata.so.46
> Note that there is only one icu lib in the ldconfig's cache. The one
> named libicudata.so.46 (which is a copy of libicudata.so.46.1).
> Questions are :
> - Why theses libs are not in the ldconfig cache ?
> - Why a copy named libicudata.so.46 is in the cache and not
Unlike the hints for the old aout format, there aren't any filename
hashes in the elf hints file, just a header and a list of search
directories. The 'ldconfig -r' output is faked, and displays (see
list_elf_hints() in src/sbin/ldconfig/elfhints.c) what it thinks
rtld(1) will look for: shared libraries in the search directories with
filenames of the form lib*.so., followed by a string of numbers
corresponding to the major version of the shared library. *.so.46.1
don't fit this pattern, because of the extra dots separating the major
and minor version numbers in those filenames.
Since your broken binary seems to need *.so.46, you can try adding
symlinks between the corresponding *.so.46 and *.so.46.1, or you can
rebuild the dependent port.
More information about the freebsd-questions