[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ports/94826: [patch] Very slow startup for libtool ltdl clients (eg
Re: ports/94826: [patch] Very slow startup for libtool ltdl clients (eg gnucash)
Wed, 22 Mar 2006 17:28:11 +0100
[ FWIW: the message has not appeared on bug-libtool yet, although I
approved it several hours ago; seems the list server is still being
worked on; anyway this is:
* Peter Jeremy wrote on Wed, Mar 22, 2006 at 09:27:31AM CET:
> libtool (ltdl) includes a check to determine whether shared
> libraries on the host OS correctly handle dependencies or whether
> libltdl needs to manually manage shared library dependencies.
> This check is implemented by hard-wiring the answer for various
> OS's, rather than testing the actual OS behaviour using a test case.
> If an OS is not listed, libltdl assumes that the OS cannot handle
> shared library dependencies. FreeBSD is not listed in the known
> OSs and libltdl therefore defaults to manual dependency loading.
> This results in massive overheads in loading programs that use
> many shared libraries. As an example, gnucash uses 122 shared
> libraries and took 15 minutes of system time to start on an XP-1800
> and a system call trace shows 24e6 open() calls.
> With libltdl_cv_sys_dlopen_deplibs=yes, the startup time drops
> to 10 seconds.
Ouch. That's disastrous.
> The critical change is the following change in output from configure:
> -checking whether deplibs are loaded by dlopen... unknown
> +checking whether deplibs are loaded by dlopen... yes
> This bug also affects other programs with ltdl embedded in them.
> Based on my collection of ports, this includes guile (prior to 1.7.2)
> and ImageMagick-126.96.36.199.
> Ideally, libtool should implement a test case to determine whether
> an OS tracks shared library dependencies or now.
This should definitely be fixed. However, I really don't know how to
write such a test so that it also works well in the cross compiling
case. So for that we would still need the table.
But at least in the non-cross-compiling case it would also fix the cases
where we are not sure whether the system supports it right, or where the
system needs some patch/upgrade to fix this issue.
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
> The following
> patches just flag that FreeBSD does track dependencies. Any one
> of the following patches should fix the problem on libtool and any
> application that embeds libltdl.
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?
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?
Cheers, and thanks very much for the bug report,
> --- ltdl.m4~ Mon Dec 19 08:53:17 2005
> +++ ltdl.m4 Wed Mar 22 18:43:11 2006
> @@ -127,6 +127,9 @@
> # If you are looking for one http://www.opendarwin.org/projects/dlcompat
> + freebsd*)
> + libltdl_cv_sys_dlopen_deplibs=yes
> + ;;
> gnu* | linux* | kfreebsd*-gnu | knetbsd*-gnu)
> # GNU and its variants, using gnu ld.so (Glibc)