libtool
[Top][All Lists]
Advanced

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

Re: LT_* equivalent to AC_CHECK_LIB?


From: Ralf Wildenhues
Subject: Re: LT_* equivalent to AC_CHECK_LIB?
Date: Mon, 3 Jul 2006 23:14:09 +0200
User-agent: Mutt/1.5.11+cvs20060403

* Tim Mooney wrote on Mon, Jul 03, 2006 at 10:50:23PM CEST:
> In regard to: Re: LT_* equivalent to AC_CHECK_LIB?, Bob Friesenhahn said...:
> 
> >Unfortunately, various OS distributions have made a habit of deleting the 
> >.la files so a LT_CHECK_LIB would not be as helpful as it might appear.
> 
> I thought about that last problem too, which makes it more difficult to
> write a robust LT_CHECK_LIB.  It probably makes sense to fall back to what
> AC_CHECK_LIB does in that case, but a macro like LT_CHECK_LIB would
> definitely need to handle the case where there are a mix of non-libtool
> and libtool libraries.

Probably, yes.

> I seem to recall discussion on this list in the past about why
> distributions were doing that, but I don't recall what any of the reasons
> were.

To avoid linking against indirect dependencies.  Or to avoid link
failure when other dependencies' .la files have been removed or moved.

> Has any work (perhaps as part of libtool 2.0) gone into addressing
> the reason(s) why they were doing that?

Hmm.  There has been quite some discussion on this and the -patches
list.  Please use the mail archives to dig it up.  I've suggested an
extensive set of testsuite tests (in some Debian bug report) which I
would see as a prerequisite to rewriting the deplib search algorithm
in ltmain.  One point is that, for consistency, the algorithm would
need to recursively include all indirect dependencies.

If anyone really cares, I can dig up a list of URLs to some important
discussion pieces.  I also have some half-finished notes, unpublished.
What is definitely lacking on my side is something like some months
with lots of time...

Cheers,
Ralf




reply via email to

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