[Top][All Lists]

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

fixes to mdemo2 - appropriate?

From: Greg Eisenhauer
Subject: fixes to mdemo2 - appropriate?
Date: Fri, 19 Sep 2003 00:46:40 -0400

Hi folks,
        Last week Gary Vaughan committed some changes to mdemo2, presumably
to make it work for non-dynamic build environments.

I introduced mdemo2 to mirror a situation in one of the packages I develop
and I'm not surprised it didn't work in the static-only situation.  That
libtool didn't do well there was one reason I wanted to introduce the test.
        But I'd like to ask the group if the changes that Gary had to
introduce to make this work make sense.  IMHO, they don't, but instead
represent a bit of a hack to cover an area where libtool isn't meeting it's
design goals.  If I'm wrong maybe someone can set me straight.
        Basically the situation is this.  mdemo2 is a simple executable that
links in an outside libtool library.  The complication is that that outside
library (../mdemo/ uses libltdl to dlopen other libraries.
Because of this, mdemo2, which doesn't directly use libltdl, must call
LTDL_SET_PRELOADED_SYMBOLS() in main(), which means it must find an
appropriate ltdl.h to include, and it must also call AC_LIBTOOL_DLOPEN in
        I understand why this is necessary given the current implementation
of libtool, but I don't think it represents a good situation.  Essentially
libtool is requiring the builders of an executable to know whether or not
any of the libraries they include might use libltdl.  libtool should be
hiding those details.
        That said, I don't have a patch to offer.  I spent a bit of time
thinking about it and wading through libtool internals a while ago, but I
came to the conclusion that I just didn't understand libtool well enough to
make the kind of structural changes that I think would be necessary.
Among other things, I think it would be necessary to generate symbol files
at link time for the library that uses libltdl (rather than at final
executable link time).  This would seem to be more in keeping with the basic
libtool paradigm that "libraries are programs..."  I.E. why does libtool
treat the final executable differently here?
        So, I thought I'd take this opportunity to try to stimulate some
discussion on this.  Am I full of it?  Or does this represent a deficiency
in libtool's handling of this situation?  If so, it a solution tenable?  Or
just too ugly to think?


greg eisenhauer
College of Computing, Georgia Institute of Technology, Atlanta, GA  30332

reply via email to

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