Re: fixes to mdemo2 - appropriate?

[Greg Eisenhauer]

Peter O'Gorman writes:
 > -----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 :)

Fair enough.

 > 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.

All true...  I knew the static case wouldn't work as desired because of the
way that libtool is currently implemented, but included it because I thought
it *should* work that way.  Simply blowing away the static test would be one
way to approach the problem, but it begs the question.
 
 > 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.

Yes, if the symbol list was built into the static library, rather than into
the final executable you'd have to make sure that the list was referenced
somehow.  Possibly tricky, but I don't think it's impossible on the face of
it.  Making it possible to put the symbol list in the static library would
have the advantage of having it generated only when the library is created,
rather than every time the library is used.  That's a fair performance win.

 > 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. 

That would be what is necessary now.  But *should* the guy linking his
executable have to know what all the transitive closure of libraries he's
using might do?  If that's what is necessary, we should document it.  Or, I
guess if we don't expect the author of main() to have all that knowledge,
then perhaps AC_LIBTOOL_DLOPEN, -dlopen force and
LTDL_SET_PRELOADED_SYMBOLS() should be the recommendation for all static
executables, just in case.  (I don't personally think either of these is
particularly attractive.)

 > Most people don't worry about the all static case.

I guess that's part of the question.  I'm not a libtool expert, but I've
been working with it for a long time and did spend some time trying to see
if I could develop a patch that addressed this situation.  I found it too
hard to wrap enough of my head around this 7K line multi-pass shell script
to even take a crack at it (of course, that was before I wrote a simple
example).  I could take a crack at it again, but does anyone care enough to
worry about it?