RE: Libtool stresstest.at segfault on Cygwin/MinGW

[Peter Ekberg]

* Ralf Wildenhues wrote on Wednesday, September 21, 2005 22:37 CEST:
> Hi Peter,
> 
> * Peter Ekberg wrote on Mon, Sep 19, 2005 at 09:05:04PM CEST:
> > Ralf Wildenhues wrote on Monday, September 19, 2005 17:10 CEST
> > > * Peter Ekberg wrote on Mon, Sep 19, 2005 at 04:17:56PM CEST:
> 
> > > > Well, the test segfaults on MinGW with the patch, and if I add
> > > > DATA to all symbols manually in asyms the (reordered) test goes
> > > > on until the same problem is triggered when export_symbols_cmds
> > > > is invoked because of the -export-symbols-regex option, so I
> > > > assume it is not good enough for MinGW. I think the import lib
> > > > gets screwed up if data symbols are not correctly tagged.
> > > 
> > > OK.  I assume it's not a linker bug then.
> > 
> > (nit: s/linker/compiler/ I suppose)
> 
> Well, I guess our current best bet is `nm', right?  ;-)

Not really, nm does as it documents. These data symbols really
are in the .text segment so T is not wrong. I still blame the
compiler for putting them there in the first place...

> > Thinking about it further, include_expsyms is perhaps not
> > buggy with skipped exports, as then the needed symbols perhaps
> > get exported anyway with the export_symbols_cmds functionality.
> > A check wouldn't hurt though...
> 
> ACK.
> 
> *big snip*
> > Ok, tested with a copy of sed in /c/foo and /c/foo/sed where the
> > patch has $SED in ltmain.m4sh, and it works. I don't know if that's
> > a good enough test for MinGW file mode issues though.
> 
> Cool.
> 
> > Updated patch attached. I think this is good to go now.
> 
> Let me just comment on it a bit more: some seds have a command limit
> (autoconf/status.m4 guesses about 100 commands), but on cygwin/mingw
> you can be sure to have a good sed available; for cross-compiles, I
> generally think we should be allowed to assume *equal or better*
> development tools on $build than on $host.

Sigh. I'll make a note in a comment...

> Another potential issue, though, with lots of symbols to 
> export, is the
> superlinear cost of lots of sed `s' commands in a script.  A totally
> unscientific test with GNU sed 4.1.2 on GNU/Linux showed a factor of
> about 2.5 time increase for twice the number of `s' commands, 
> when used
> on a file where each command matches once; but with nicely 
> spread symbol
> names.  With `join', this issue could easily be fixed, but it's not
> available on mingw (and not in the list of allowed tools).  :-/
> 
> In short: yes, please apply, and add a FIXME comment to look out for a
> potential bottleneck.  :)

Lots of 's' commands imply lots of global variables in this
case. And if you have houndreds of global variables you deserve
to *suffer* :-)

I'll make another note though...

> Cheers, and thank you,
> Ralf

Well, cheers, and thank you for all your reviews,
Peter

PS. applied this:

Index: libltdl/config/ltmain.m4sh
===================================================================
RCS file: /cvsroot/libtool/libtool/libltdl/config/ltmain.m4sh,v
retrieving revision 1.9
diff -u -r1.9 ltmain.m4sh
--- libltdl/config/ltmain.m4sh  21 Sep 2005 12:32:42 -0000      1.9
+++ libltdl/config/ltmain.m4sh  22 Sep 2005 07:39:41 -0000
@@ -4933,6 +4933,26 @@
        # Use standard objects if they are pic
        test -z "$pic_flag" && libobjs=`$ECHO "X$libobjs" | $SP2NL |
$Xsed -e "$lo2o" | $NL2SP`
 
+       orig_export_symbols=
+       case $host_os in
+       cygwin* | mingw*)
+         if test -n "$export_symbols" && test -z
"$export_symbols_regex"; then
+           # exporting using user supplied symfile
+           if test "x`$SED 1q $export_symbols`" != xEXPORTS; then
+             # and it's NOT already a .def file. Must figure out
+             # which of the given symbols are data symbols and tag
+             # them as such. So, trigger use of export_symbols_cmds.
+             # export_symbols gets reassigned inside the "prepare
+             # the list of exported symbols" if statement, so the
+             # include_expsyms logic still works.
+             orig_export_symbols="$export_symbols"
+             export_symbols=
+             always_export_symbols=yes
+           fi
+         fi
+         ;;
+       esac
+
        # Prepare the list of exported symbols
        if test -z "$export_symbols"; then
          if test "$always_export_symbols" = yes || test -n
"$export_symbols_regex"; then
@@ -4966,7 +4986,22 @@
        fi
 
        if test -n "$export_symbols" && test -n "$include_expsyms"; then
-         $opt_dry_run || eval '$ECHO "X$include_expsyms" | $Xsed |
$SP2NL >> "$export_symbols"'
+         tmp_export_symbols="$export_symbols"
+         test -n "$orig_export_symbols" &&
tmp_export_symbols="$orig_export_symbols"
+         $opt_dry_run || eval '$ECHO "X$include_expsyms" | $Xsed |
$SP2NL >> "$tmp_export_symbols"'
+       fi
+
+       if test "X$skipped_export" != "X:" && test -n
"$orig_export_symbols"; then
+         # The given exports_symbols file has to be filtered, so filter
it.
+         func_echo "filter symbol list for \`$libname.la' to tag DATA
exports"
+         # FIXME: $output_objdir/$libname.filter potentially contains
lots of
+         # 's' commands which not all seds can handle. GNU sed should
be fine
+         # though. Also, the filter scales superlinearly with the
number of
+         # global variables. join(1) would be nice here, but
unfortunately
+         # isn't a blessed tool.
+         $opt_dry_run || $SED -e '/[[ ,]]DATA/!d;s,\(.*\)\([[
\,]].*\),s|^\1$|\1\2|,' < $export_symbols >
$output_objdir/$libname.filter
+         export_symbols=$output_objdir/$libname.def
+         $opt_dry_run || $SED -f $output_objdir/$libname.filter <
$orig_export_symbols > $export_symbols
        fi
 
        tmp_deplibs=