Re: ldconfig

[Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>]

Justin Pryzby <justinpryzby@users.sourceforge.net> writes:

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

It goes through the system dirs and then anything in ld.so.conf.

> 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
> name.  Right?

Why should the cache not get updated? That would be bad as it would
then look for the old library on updates. The reason why the link
should be included is so that the library can already be used between
unpacking and configuring (running ldconfig) 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..

It is because dpkg does not provide a run-one-at-the-end hook. If
every other package would start reimplementing their own hook system
that would be bad and stupid. Someone has to implement a consitent
hook system for dpkg and then we can use that for ldconfig calls too.

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

My understanind too is that (provided the links are shipped) then
running ldconfig is purely a speedup but in no way affect the
usability. For packages without the lib that is another story:

Say libfoo depends on bar and bar depends on libbar. libfoo calls bar
in postinst. If libbar ships no libbar.so.x link and ldconfig is not
run then it is my understanding that bar fails to start. libfoo
postinst then fails.


If someone makes a run-ldconfig-once hook then having the links
shipped would be a prerequisite to using the hook. Easily enough to
demand that for its use.

> Justin

MfG
        Goswin