[ 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: http://www.freebsd.org/cgi/query-pr.cgi?pr=94826 ]
Hi Peter, * 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. Confirmed. > 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 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-6.2.5.5. Yes. > >Fix: > 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 open. > 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, Ralf > --- 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 > libltdl_cv_sys_dlopen_deplibs=yes > ;; > + freebsd*) > + libltdl_cv_sys_dlopen_deplibs=yes > + ;; > gnu* | linux* | kfreebsd*-gnu | knetbsd*-gnu) > # GNU and its variants, using gnu ld.so (Glibc) > libltdl_cv_sys_dlopen_deplibs=yes _______________________________________________ Bug-libtool mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-libtool
