Re: libtool --mode=execute regressions

[Ralf Wildenhues]

* Gary V. Vaughan wrote on Thu, Sep 16, 2004 at 06:51:52PM CEST:
> Ralf Wildenhues wrote:
> > With CVS HEAD libtool,
> > $ libtool --mode=execute -dlopen foo.la ./main
> > does not work:
> > | libtool: execute: unrecognized option `-dlopen'
> > | libtool: execute: Try `libtool --help' for more information.
> > 
> > It accepts only --dlopen, contradicting both `libtool --mode=execute --help'
> > and
> > $ info '(libtool.info)Execute mode'
> 
> Actually, I had wondered why -dlopen (or --dlopen as I spelled it) was parsed
> in the main argument parsing loop near the top of ltmain.in, and I guess it
> was for this feature of execute mode.
> 
> > Furthermore, with --dlopen it does not work either, because the foo.la item 
> > is
> > not shifted away:
> > 
> > $ ./libtool -n --mode=execute --dlopen foo.la ./main
> > LD_LIBRARY_PATH=/tmp/build/.libs
> > export LD_LIBRARY_PATH
> > foo.la "./main"
> 
> Ah, boo.  My bad.  The attached patch is a correct fix.

Yep.  Thanks!

> > For completeness, a testcase tarball is attached.  No patch because I
> > don't know if the change of published interfaces was intended or not.
> > If wanted, I might rewrite the test for suitable inclusion into the
> > testsuite.
> 
> That would be *great*.  Especially if you submitted it as our first Autotest
> test case :-)  The hooks are in configure.ac and just need uncommenting, and
> then the test case itself needs to be written.  CVS m4 provides a good model
> for writing Autotest cases if you need a leg up.

Will do eventually.

> You would either need to use libltdl to get symbol addresses (which probably
> defeats the object) or else be intelligent about SKIPping the test if there
> is no dlopen/dlsym api.

Yes, using libltdl completely defeats the test.

> > Out of curiosity a question: If, in this testcase, I change
> >   LT_INIT(dlopen)
> > to plain
> >   LT_INIT
> > then libtool generates a wrapper for the program, and then executing
> >   ./main
> > obviously works.  By using only the documentation, I could not make
> > sense of this difference in behaviour (except the latter might just be
> > disallowed use of libtool, that just happened to work "by chance").
> 
> The libtool usage is allowed, and all that happens is -dlopen downgrades to
> -dlpreopen and in addition to the wrapper script libtool preloads the foo
> module in a way suitable for lt_dlopening with the preopen.c loader.  It is
> just a happy coincidence that you can use dlopen successfully inside a wrapper
> script even though you have told libtool that it doesn't work ;-)

Ok, thanks for the explanation.  That testcase might just grow to be two
testcases then.

Another question, while we're at it:  Is using libltdl without having
its sources within the package tree supported?  The documentation is
rather vague and hard to understand on this issue.  If it is, there'll
be more tests currently failing to be submitted..

Regards,
Ralf