[Top][All Lists]
[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