Bug#72140: Setting up libraries too slow
#include <hallo.h>
* Tim Connors [Thu, Jun 22 2006, 06:03:41PM]:
> > 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
Yed, ldconfig calls suck. I noticed that on a machine with "low memory"
(less than 256MB), too many programs do too much things in postinst, so
the VFS cache seems to become useless and the contents is exchanged all
the time.
Please read
http://people.debian.org/~terpstra/message/20060312.125613.c03ce487.en.html
and following. I stopped working on a proof-of-concpet after writting
the base specs (see wiki link there) because of not having enough spare
time and the requirement of dpkg modification (for LD_LIBRARY_PATH
export/preset).
If you wish to take it over, let us know and go ahead.
> 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.
*g*... yes, AFAICS only the programs working with dlopen and
non-standard paths do not cope with not having the up-to-date
ld.so.cache. We could forbid the usage of such programs in the postinst
via policy, make dpkg prepend a NOOP-symlink for ldconfig in the $PATH
and everything should be fine RSN.
> 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.
That was the quick fix I suggested, the "better" solution is the
dpkg-hook idea.
Eduard.
Reply to: