[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: Ralf Wildenhues
Subject: Re: ports/94826: [patch] Very slow startup for libtool ltdl clients (eg gnucash)
Date: Fri, 24 Mar 2006 09:57:10 +0100
User-agent: Mutt/1.5.11

Hi Noah,

* Noah Misch wrote on Fri, Mar 24, 2006 at 01:45:33AM CET:
> On Wed, Mar 22, 2006 at 05:28:11PM +0100, Ralf Wildenhues wrote:
> > * Peter Jeremy wrote on Wed, Mar 22, 2006 at 09:27:31AM CET:
> > >   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.
> A native build could use the test but compare the result with the tabulated
> value used for cross-compiling, perhaps asking the user to report 
> discrepancies.

Yes.  But then I think it's not so much better than a good testsuite
test that reports this, but carries the overhead that every package has
to ship with this test.

Let's be realistic here: Libtool is a package that pretty much needs to
be adapted for each new system it should support (except that static
libraries should work out-of-the-box); this was recognized a long time
ago, and consequently, it has very few runtime tests (compared to the
number of decisions) in its configuration, which at least takes away
some of the configure-time-overhead burden away from the end user.

So, when we accept the fact that Libtool needs active porting, the
remaining point is IMVHO that we should improve the test suite insofar
that it has a chance to expose as many missing or wrong settings.
Then a passing testsuite is a good indication of a good port.

Actually, I think we're moving in the right direction with the test
suite of CVS HEAD Libtool.

Also please note that a portable way of testing above feature would
incur quite a large overhead: basically the libltdl loaders would
need to be provided from within `configure', the right one compiled,
and then the test itself.  I don't think that is such a good idea.


reply via email to

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