[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ports/94826: [patch] Very slow startup for libtool ltdl clients (eg

From: Peter Jeremy
Subject: Re: ports/94826: [patch] Very slow startup for libtool ltdl clients (eg gnucash)
Date: Thu, 23 Mar 2006 05:42:33 +1100
User-agent: Mutt/1.5.11

I should acknowledge that the problem and fix were pointed out by

On Wed, 2006-Mar-22 17:28:11 +0100, Ralf Wildenhues wrote:
>I'll put adding such a test on the TODO list.  I'll also put reworking
>the manual loading algorithm on the TODO list, it shouldn't scale
>nonlinearly in the number of loaded deplibs, however many modules we

I've still got a trace of all calls to lt_dlopenext() during gnucash
startup but I've cleaned up the more detailed debugging output that
I collected (though I could probably re-create it).

I suspect it's a combination of:
- both dlopen() and lt_dlopen() are recursively attempting to load
- The .la file can contain duplicate dependencies (which don't appear
  to be stripped out)
- It looks like duplicate entries in the library search path
  (inherited from LD_LIBRARY_PATH and added via .la) aren't deleted
- Tracking lt_dlopen/lt_dlclose shows that libraries are being opened
  and closed multiple times during startup.

Before joerg pointed me in the right direction, I was looking at
adding caching to lt_dlopenext() or lt_dlopen() but hadn't worked out
how to correctly track reference counts across open/close calls.

>Thanks for the patch.  A question before I apply it: this should work on
>DragonFly as well, right?  Could somebody confirm this, to avoid another
>bug report to this end?

joerg found the problem using KDE on DragonFly.

>Also, has the FreeBSD rtld always supported loading dependent libraries
>upon dlopen() (including honoring DT_RPATH entries in the module) or was
>this not working at some point in the past?

AFAIK, it's worked since FreeBSD transitioned to ELF (FreeBSD3.0).  I'm
not sure about the a.out rtld but FreeBSD 2.x is ancient history.

Peter Jeremy

reply via email to

[Prev in Thread] Current Thread [Next in Thread]