On Fri, 19 Sep 2003, Greg Eisenhauer wrote: > 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/libmlib.la) 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 > its configure.ac. > 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.
I don't believe that libtool should be hiding this particular detail. If a library uses libltdl then it must provide a means to initialize it. Typically this could be done by requiring that a library initialization function be executed before any other library function is invoked. This library initialization function can invoke LTDL_SET_PRELOADED_SYMBOLS() if necessary. There is no need for the dependent application to include ltdl.h or (knowingly) invoke LTDL_SET_PRELOADED_SYMBOLS(). Use of preloaded symbols is optional. Libltdl can be used as a portable dlsym() API and there are other ways to handle static builds besides the preloaded symbols approach. In these cases, automatically invoking LTDL_SET_PRELOADED_SYMBOLS() from main() would be counterproductive. Bob ====================================== Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen _______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
