Hello Charles,
thanks for the patch! Quoting a bit out of order:
* Charles Wilson wrote on Sat, May 31, 2008 at 07:01:45PM CEST:
> * libltdl/config/ltmain.m4sh (func_enable_tag): allow
> --verbose to set opt_verbose
[...]
> A) libtool --verbose does not actually set opt_verbose. In fact,
> nothing ever sets opt_verbose true. Should all uses of opt_verbose
> be replaced by !opt_silent, or should (as I have done in this patch)
> --verbose set both opt_silent false, and opt_verbose true?
Well, --verbose is documented to be a reversal of --silent, and
documented to be the default. The fact that opt_verbose is never set is
a limitation. If fixed, that should better happen in a separate patch.
Several possibilities:
- a new switch for being very verbose.
- allowing
--verbose
--silent --verbose --verbose
to output verbose output. That way one can still undo the effects of
--silent without verbose output; however, now the user needs to know
whether --silent was passed earlier on the command line (this is a
backward incompatibility). Not nice (imagine --silent being passed in
AM_LIBTOOLFLAGS).
- some other way out... ?
Not sure which way to go here. But in any case, moving forward here
would need changes to libtool.texi, NEWS, 'libtool --help' output, and
testsuite additions.
> B) func_win32_libid() gives some confusing errors to users
> when (a) using recursive make, and (b) MAKEFLAGS does not
> contain $OBJDUMP. Add a diagnostic error message, rather
> than allowing $SED to die a horrible death.
Why should external variables ever matter here? OBJDUMP is initialized
at the top of the libtool script. It should come from _LT_DECL_OBJDUMP
in libtool.m4, and always be set to nonempty. If it is empty, then the
package author forgot the `win32-dll' option in LT_INIT, resp. the
AC_LIBTOOL_WIN32_DLL macro. Likewise for DLLTOOL. Both could be set to
'false' if not present.
Anyway, if this should be needed, then it should be a separate change as
well, and it should be a warning that hints to above macros, and it
should be put in a place where we first decide whether it's necessary,
when creating a DLL. Also, this needs mention in the ChangeLog entry,
as you already noted. Or maybe you have a test case where
_LT_DECL_OBJDUMP isn't used, then that would need fixing (and a
testsuite addition).
Now to the meat of the patch:
> When configuring with --disable-static, dlpreopen is very confused.
> First, libtool tries to extract the symbols -- using $NM and
> $global_symbols_pipe -- from the DLL. That works...poorly:
>
> Here's a snippet from helldl.exeS.c when --disable-static:
> ======
> /* External symbol declarations for the compiler. */
> extern int _CTOR_LIST__();
> extern int _DTOR_LIST__();
> extern char _RUNTIME_PSEUDO_RELOC_LIST_END__;
> extern char _RUNTIME_PSEUDO_RELOC_LIST__;
> extern int __CTOR_LIST__();
> extern int __DTOR_LIST__();
> ...
> extern int printf();
> extern int puts();
> extern int realloc();
OK, I see that this is problematic. What I don't understand yet is:
is there a way to extract only the interesting symbols from the DLL?
I don't yet understand why we have to move to the import library.
Once I understand that, I can better judge the rest of the patch.
A couple of general remarks though:
- there is no need to use $EGREP with literals; grep can do that, or
case `$command` in *literal*) ... ;; esac
which avoids a second fork.
- the code uses eval several times; I think it is really only necessary
in lines that contain, for example, '| $global_symbol_pipe ...', or
$file_magic_cmd.
Unrelated to your current efforts, but at one point we really have to
stop adding more 'case $host in *mingw*...' statements all over the
place. Each time I read them, I stop and ask myself "which other w32
systems should be listed here, too, like cegcc?" These instances
generally lead to trouble when adding new systems. In turn, that likely
means we need to define more libtool variables describing the system
peculiarities that are currently all hidden behind mingw, cygwin etc.
(Not asking you to do this, but for example mentioning in the mail
whether you considered cygwin or cegcc or so would be helpful for
review).
Cheers, and thanks,
Ralf
