libtool-patches
[Top][All Lists]
Advanced

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

Re: libdlloader.so ... die, die, die!


From: Ralf Wildenhues
Subject: Re: libdlloader.so ... die, die, die!
Date: Mon, 22 Nov 2004 12:22:04 +0100
User-agent: Mutt/1.4.1i

* Bob Friesenhahn wrote on Sun, Nov 21, 2004 at 06:06:58PM CET:
> On Sun, 21 Nov 2004, Peter O'Gorman wrote:
> >Bob Friesenhahn wrote:
> >>How did the mandatory libdlloader.so beast come to be and how can we kill 
> >>it?
> >
> >Gary did not seem to think this a showstopper for 2.0, if we all gang up 
> >and each buy him a beer he may see things more clearly :)
> >
> ><http://article.gmane.org/gmane.comp.gnu.libtool.patches/2891>

I may be dense, but:  Why does it have to be that way?
I haven't tried it yet, but if you use libltdlc.la, why can you not
just link against the uninstalled libdlloader.la?

If this is a libltdl-internal problem, can someone explain this to me in
a detailed way?

> Clearly my opinion differs from Gary's in this regard, and I expect 
> that my opinion will be shared by all existing libltdl users (except 
> for perhaps Gary).  There is a point where the cost outweighs the 
> merits.  Libltdl has gone from a directory containing only two source 
> files and a trivial build to a complicated build containing multiple 
> directories, many source files, and two libraries, one of which 
> doesn't provide any user APIs.

If (and only if) above questions have negative answers, then I vote for
eliminating libdlloader.

> This weekend I have been working on updating GraphicsMagick to use the 
> 2.0 libltdl.  It has been slow-going.  The first test build used the 
> installed libltdl (which it should have) but all the C++ tests failed 
> so I will have to look into that.

May I just thank you for doing this painful task and promise to buy you
a beer for this if we ever meet!

Cheers,
Ralf




reply via email to

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