My understanding is that ldconfig does 2 things:
1. Create symbolic links
/usr/lib/foo.so.n is made a link to the most recent library whose
soname is foo.so.n; nothing happens if this is already true.
2. Update the cache file /etc/ld.so.cache
If a library is needed (eg. during loading of a process by the
dynamic linker) and its soname is found in the cache, it can be
accessed directly; strace a process to see this (open, read,
mmap, close, ...). If its soname is not found in the cache, ld
goes through a sequence of up to (at least a possibility of) 12
directories, I guess in some priority order, in an attempt to
find the library (actually, the runtime symlink, as created
Policy 8.1. already recommends ("should") that packages include the
runtime symlink. If it *is* included, ldconfig won't update the
cache, since only one version of a shared library can be installed at
a time, since the shared library version is a part of the package
Policy requires running ldconfig to avoid having to unnecessarily
search for potentially many libraries at each program execution; this
makes perfect sense.
However, ldconfig is pretty slow on some machines, eg. laptops with
slow disks or low memory. Dist-upgrading presently requires running
ldconfig once for each installed or upgraded library; on a machine
with a fast disk or lots of ram to cache /usr/lib/, this doesn't
matter much; only the first execution will be slow. I know this has
been discussed before (#68981), but I still don't understand why can't
happen just once, at the end of the dpkg run. Is it, at this point,
just because dpkg doesn't support this kind of hook/trigger/affects?
If so, it would be useful for some program to include
../something/ldconfig-once, in the style of the
backgrounded-menu-updates-after-dpkg-exits, and debhelper to use that
instead of calling ldconfig directly. Ack that it is ugly..
Some of the bug logs indicate that dependencies will be broken if
ldconfig is only run once; my understanding is that this is not true.
But maybe I misunderstand something..
- Re: ldconfig
- From: Goswin von Brederlow <email@example.com>