Re: fixes to mdemo2 - appropriate?

[Peter O'Gorman]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Well, as the author of those fixes, I'd first like to question whether
the test itself was appropriate, rather than the fixes :)

In your original test, it builds mdemo2_static and mdemo2 binaries (if I
recall correctly). The static program had no hope of working because the
symbol list did not get included in the executable. If I set the env var
to allow ltdl to find the dynamic libraries then it does indeed run, but
it is no longer a static program, it is dynamically loading the module.

~ Similarly the mdemo2 executable which is meant to dlopen everthing in
fact links the module .a's (of course the linker will discard them as
the symbols aren't actually used anywhere), but does successfully run
and load the modules. I was thinking of simply deleting the static
program and adding the AC_LIBTOOL_DLOPEN in configure.ac.

As to why the symbol list is not simply included in the library, the
linker would discard everything as unused, because in the main program,
they would be. If you can think of some way around this, fair play to you.

Basically, if you think your program may dlopen something, but you don't
know what, you should do the AC_LIBTOOL_DLOPEN check and, if you are
using ltdl and you want static to work, add the -dlopen force flag and
LTDL_SET_PRELOADED_SYMBOLS() in the main program. Most people don't
worry anout the all static case.

Does this help?

Peter

Greg Eisenhauer wrote:

|
| Hi folks,
|       Last week Gary Vaughan committed some changes to mdemo2, presumably
| to make it work for non-dynamic build environments.
|     http://mail.gnu.org/archive/html/libtool-commit/2003-09/msg00003.html
|
| 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/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.
|       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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQE/awlChJEqt987YAQRAj5nAKCwTNgkF+GsEwxEgGthS4oSu2yPOQCeLj2l
xp2KT3Bd5t5YSRpneOTMWOg=
=Nk6w
-----END PGP SIGNATURE-----