* 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=
