Re: libtool --mode=execute regressions

[Gary V. Vaughan]

Hallo Ralf,

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.

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

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.

> 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 ;-)

Cheers,
        Gary.
-- 
Gary V. Vaughan      ())_.  address@hidden,gnu.org}
Research Scientist   ( '/   http://tkd.kicks-ass.net
GNU Hacker           / )=   http://www.gnu.org/software/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook

* looking for address@hidden/libtool--devo--1.0--patch-185 to compare with
* comparing to address@hidden/libtool--devo--1.0--patch-185
M  config/ltmain.in
 
* modified files
 
--- orig/config/ltmain.in
+++ mod/config/ltmain.in
@@ -618,8 +618,9 @@
                        set -x
                        ;;
  
-      --dlopen)                test "$#" -eq 0 && func_missing_arg "$opt" && 
break
+      -dlopen)         test "$#" -eq 0 && func_missing_arg "$opt" && break
                        execute_dlfiles="$execute_dlfiles $1"
+                       shift
                        ;;
  
       --dry-run | -n)  run=:                                           ;;
@@ -663,7 +664,7 @@
                        ;;
  
       # Separate optargs to long options:
-      --dlopen=*|--mode=*|--tag=*)
+      -dlopen=*|--mode=*|--tag=*)
                        arg=`echo "$opt" | $SED "$my_sed_long_arg"`
                        opt=`echo "$opt" | $SED "$my_sed_long_opt"`
                        set -- "$opt" "$arg" ${1+"$@"}

signature.asc
Description: OpenPGP digital signature