Bug#72140: Setting up libraries too slow
> On Sun, Sep 24, 2000 at 02:24:43PM +0200, Torsten Landschoff wrote:
> > On Sat, Sep 23, 2000 at 01:54:17PM -0400, nveber@primusolutions.net wrote:
> > > root@pyre[~]# /usr/bin/gkrellm
> > > /usr/bin/gkrellm: error in loading shared libraries: libXi.so.6: cannot open
> > > shared object file: No such file or directory
> >
> > Right, forgot about this. The dynamic linker does not actually use
> > /etc/ld.so.conf but only /etc/ld.so.cache. So if you don't have the lib
> > in the system path it may well be not found.
> >
> > > I think setting one envoromnment variable is slightly faster than running
> > > ldconfig :)
> >
> > Yep, but this is more error prone. You can easily forget to do that since
> > you need to do it in all postinst which depend on that library...
> >
> > Contrary ldconfig needs to be run in the lib installation script.
> >
> > > PS. Anyone know what other distro's (redhat?) do? Installing rpm's seems
> > > faster than .deb's, but I dont know if that has anything to do with this
> > > issue.
> >
> > I think they don't call ldconfig.
> >
> > Summary: Perhaps we should
> >
> > a) remove that ldconfig call from the library postinsts
> > b) make dpkg call ldconfig if any of /usr/lib, /lib or the dirs in
> > /etc/ld.so.conf has been touched since starting dpkg
> > c) demand that postinst which call programs with libs outside
> > /lib and /usr/lib sets LD_LIBRARY_PATH
>
> How about:
>
> a) remove the ldocnfig call from the library postinsts
> b) make dpkg set the LD_LIBRARY_PATH if its installing a library
> This would be a global setting that every program inherits, and would
> not
> require each library to modify its postinst, and set variables..
> c) call ldconfig at the end of the install/upgrade
This bug is still here, as bad as ever, after 6 years.
ldconfig is still dog slow. I am using an ext3 fs, and ldconfig and
hence dpkg is not quicker the second time around -- one suspects ldconfig
is trying to read so much cruft that any information has been long purged
out of the filesystem cache before ldconfig is invoked the second time.
However, for the past 12 months, I have been symlinking /sbin/ldconfig to
/bin/true after moving ldconfig to ldconfig.real, with much success. No
crashes so far, no missing libraries, only the occasional slowness as apt
replaces libc6 and the /sbin/ldconfig program gets restored. I move it
back out of the way when I notice that apt is taking so long, and all is
fine.
Occasionally, if I feel like it, I manually run /sbin/ldconfig.real, but
I notice no difference whether the cache is updated or not. I only notice
it when it is being run during an package uprade or installation and it
takes 3 minutes per invocation, which tells me the cache is largely
useless.
I think the ldconfig calls should be removed from all packages, after
changing policy. It seriously takes 10 times longer to update my system
if those useless calls are made. If you really need to, make a log in
each postinst that *thinks* it needs ldconfig, and if one package thought
it needed it, run it at the end just before dpkg exits. Don't just
blindly run it everytime dpkg is invoked, because I may well have
installed just one package rather than upgrading the system, and it may
well have not required ldconfig.
Perhaps, instead of changing policy, a quick fix: You don't need to
implement triggers properly -- you could just write something that logs
that ldconfig needs to be called later, call it /usr/lib/dpkg/ldconfig,
prepend /usr/lib/dpkg: to $PATH for everything dpkg spawns, and the new
file gets invoked in preferance to /sbin/ldconfig.
--
TimC -- http://http://astronomy.swin.edu.au/staff/tconnors/
>Cats are intended to teach us that not everything in nature has a function.
You're saying cats are the opposite of bijectiveness?
-- ST in RHOD
Reply to: