Re: bug#13462: error: file 'build-aux/funclib.sh' not found
On 2013-01-16 18:00, Peter Rosin wrote:
Hi!
If I, in a dirty git checkout (added an insignificant newline) as
of today, do this
./bootstrap -fc
cd ..
mkdir foo
cd foo
../libtool/configure
make
make check
all is fine. If I then modify build-aux/ltmain.in (with another
insignificant newline) followed by
make
or
make check
I get:
GEN ../libtool-msvc/build-aux/ltmain.sh
inline-source: error: file 'build-aux/funclib.sh' not found
inline-source: error: file 'build-aux/options-parser' not found
GEN libtool
followed by numerous failures that appear to be related.
Hi!
This appears to fix it. Ok to commit?
Cheers,
Peter
From 3723f8cf69192cf09825a52447652ae47f8f Mon Sep 17 00:00:00 2001
From: Peter Rosin p...@lysator.liu.se
Date: Fri, 18 Jan 2013 10:40:37 +0100
Subject: [PATCH] maint: find external libraries from a VPATH build
Fixes bug#13462.
* build-aux/ltmain.in: Assume that the external libraries are in the
same directory as this script.
Signed-off-by: Peter Rosin p...@lysator.liu.se
---
build-aux/ltmain.in |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index c8cdb9c..2e85cb0 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -61,8 +61,8 @@ package_revision=@package_revision@
# Much of our low-level functionality needs to be sourced from external
# libraries, which are installed to $pkgauxdir.
-. build-aux/funclib.sh
-. build-aux/options-parser
+. `echo $0 |${SED-sed} 's|[^/]*$||'`funclib.sh
+. `echo $0 |${SED-sed} 's|[^/]*$||'`options-parser
# Set a version string.
scriptversion='(GNU @PACKAGE@) @VERSION@'
--
1.7.9
Re: bug#13414: Valid DLL def file mangled by libtool
Hi Martin, Erik, On 2013-01-12 01:26, Peter Rosin wrote: Hi Martin, Thanks for the report. On 2013-01-11 12:34, Martin Doucha wrote: Hi, I'd like to report a bug in libtool 2.4 (including the latest git revision) which mangles valid DLL def files under MinGW and makes the linker barf. The bug is caused by incorect check for EXPORTS keyword in the def file which libtool does this way: if test x`$SED 1q $export_symbols` != xEXPORTS; then ... [add another EXPORTS line at the beginning of file] This test is incorrect because the EXPORTS keyword does not have to appear on the very first line. You should replace the test with this: if test x`$GREP EXPORTS $export_symbols` != xEXPORTS; then ... Also note that this test appears on several places throughout libtool sources (both as xEXPORTS and just EXPORTS) so you need to fix all of them. This issue has been reported before [1]. It's been on my back burner for a while, but I've been held up by build system issues. At least, that's my excuse :-) Anyway, I think your suggested alternative with grep is a bit too relaxed, as any symbol involving the substring EXPORTS would trigger it. Also, it scans the whole file, which is suboptimal. I'm looking into a patch that uses $SED -n \ -e '/^[ ]*//' \ -e '/^;/D' \ -e '/^$/D' \ -e 's/^EXPORTS.*/DEF/p' \ -e 's/^LIBRARY.*/DEF/p' \ -e q \ $export_symbols instead (coupled with a test for DEF instead, naturally). Does anybody have any issues with such a beast? Yes, I know that it will not catch any valid .def file, but I don't fancy writing a full .def file parser for this [2]. The above steps past initial comment and whitespace lines waiting for the first real line, and triggers if it starts with EXPORTS or LIBRARY (at least, that's the intention...) [1] http://lists.gnu.org/archive/html/libtool/2012-02/msg00023.html [2] http://msdn.microsoft.com/en-us/library/h41zhe21(v=vs.110).aspx I'm back, with suggested changes against latest git, and I'm curious if it is enough to solve your problem? If you are not able to check for some reason, it might be possible for you to provide the .def file you had the problem with? (this question was mainly for Martin, Erik had enough specifics in his report) Also, while I recognize that my evaluation of Martin's patch was flawed in that his grep-based patch doesn't trigger on any symbol with EXPORTS as a substring (which I stated, I was using the mental model of my patch on his code, and stumbled), it still reads the whole .def file and doesn't catch .def files with a symbol on the same line as the EXPORTS keyword... So, as hinted above, I'm following up with a pair of patches that appear to mend this. Ok to push? Or are the white-space changes in the first patch too intrusive? Cheers, Peter
[PATCH 1/2] libtool: allow tabs in $cmds variables
build-aux/ltmain.in (func_execute_cmds, func_mode_link): Don't collapse
tabs and surrounding whitespace into a single space when executing a
tilde-separated cmds construct, instead keep any tabs intact.
m4/libtool.m4: Convert indenting tabs to spaces for all *_cmds
variables affected by the above.
Signed-off-by: Peter Rosin p...@lysator.liu.se
---
build-aux/ltmain.in |8 ++-
m4/libtool.m4 | 170 +-
2 files changed, 91 insertions(+), 87 deletions(-)
diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index c8cdb9c..eb224e3 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -656,8 +656,10 @@ func_execute_cmds ()
save_ifs=$IFS; IFS='~'
for cmd in $1; do
- IFS=$save_ifs
+ IFS=' ''
+'
eval cmd=\$cmd\
+ IFS=$save_ifs
func_show_eval $cmd ${2-:}
done
IFS=$save_ifs
@@ -7964,8 +7966,10 @@ EOF
save_ifs=$IFS; IFS='~'
for cmd in $cmds; do
- IFS=$save_ifs
+ IFS=' ''
+'
eval cmd=\$cmd\
+ IFS=$save_ifs
$opt_quiet || {
func_quote_for_expand $cmd
eval func_echo $func_quote_for_expand_result
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index eb44de6..4bc9e98 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -4785,12 +4785,12 @@ _LT_EOF
# If the export-symbols file already is a .def file (1st line
# is EXPORTS), use it as is; otherwise, prepend...
_LT_TAGVAR(archive_expsym_cmds, $1)='if test EXPORTS = `$SED 1q
$export_symbols`; then
- cp $export_symbols $output_objdir/$soname.def;
- else
- echo EXPORTS $output_objdir/$soname.def;
- cat $export_symbols $output_objdir/$soname.def;
- fi~
- $CC -shared $output_objdir/$soname.def $libobjs $deplibs
$compiler_flags -o $output_objdir/$soname $wl--enable-auto-image-base -Xlinker
--out-implib -Xlinker $lib'
+ cp $export_symbols $output_objdir/$soname.def;
+else
+ echo EXPORTS $output_objdir/$soname.def;
+ cat $export_symbols $output_objdir/$soname.def;
+fi~
+$CC -shared $output_objdir/$soname.def $libobjs $deplibs
$compiler_flags -o $output_objdir/$soname $wl--enable-auto-image-base -Xlinker
--out-implib -Xlinker $lib'
else
_LT_TAGVAR(ld_shlibs, $1)=no
fi
@@ -4868,9 +4868,9 @@ _LT_EOF
if test yes = $supports_anon_versioning; then
_LT_TAGVAR(archive_expsym_cmds, $1)='echo { global:
$output_objdir/$libname.ver~
- cat $export_symbols | sed -e s/\(.*\)/\1;/
$output_objdir/$libname.ver~
- echo local: *; }; $output_objdir/$libname.ver~
- $CC '$tmp_sharedflag$tmp_addflag' $libobjs $deplibs
$compiler_flags $wl-soname $wl$soname $wl-version-script
$wl$output_objdir/$libname.ver -o $lib'
+cat $export_symbols | sed -e s/\(.*\)/\1;/
$output_objdir/$libname.ver~
+echo local: *; }; $output_objdir/$libname.ver~
+$CC '$tmp_sharedflag$tmp_addflag' $libobjs $deplibs
$compiler_flags $wl-soname $wl$soname $wl-version-script
$wl$output_objdir/$libname.ver -o $lib'
fi
case $cc_basename in
@@ -4881,9 +4881,9 @@ _LT_EOF
_LT_TAGVAR(archive_cmds, $1)='$LD -shared $libobjs $deplibs
$linker_flags -soname $soname -o $lib'
if test yes = $supports_anon_versioning; then
_LT_TAGVAR(archive_expsym_cmds, $1)='echo { global:
$output_objdir/$libname.ver~
- cat $export_symbols | sed -e s/\(.*\)/\1;/
$output_objdir/$libname.ver~
- echo local: *; }; $output_objdir/$libname.ver~
- $LD -shared $libobjs $deplibs $linker_flags -soname $soname
-version-script $output_objdir/$libname.ver -o $lib'
+ cat $export_symbols | sed -e s/\(.*\)/\1;/
$output_objdir/$libname.ver~
+ echo local: *; }; $output_objdir/$libname.ver~
+ $LD -shared $libobjs $deplibs $linker_flags -soname $soname
-version-script $output_objdir/$libname.ver -o $lib'
fi
;;
esac
@@ -5163,13 +5163,13 @@ _LT_EOF
# FIXME: Setting linknames here is a bad hack.
_LT_TAGVAR(archive_cmds, $1)='$CC -o $output_objdir/$soname $libobjs
$compiler_flags $deplibs
-Wl,-DLL,-IMPLIB:$tool_output_objdir$libname.dll.lib~linknames='
_LT_TAGVAR(archive_expsym_cmds, $1)='if test EXPORTS = `$SED 1q
$export_symbols`; then
- cp $export_symbols $output_objdir/$soname.def;
- echo $tool_output_objdir$soname.def
$output_objdir/$soname.exp;
- else
- $SED -e '\''s/^/-link -EXPORT:/'\'' $export_symbols
$output_objdir/$soname.exp;
- fi~
- $CC -o $tool_output_objdir$soname $libobjs $compiler_flags $deplibs
@$tool_output_objdir$soname.exp
-Wl,-DLL,-IMPLIB:$tool_output_objdir$libname.dll.lib~
- linknames='
+cp $export_symbols $output_objdir/$soname.def;
+echo
[PATCH 2/2] libtool: factor out the dll .def file test and improve it
Resolves bug#13414. Problem reported by Erik van Pienbroek
and Martin Doucha.
build-aux/ltmain.in (func_mode_link): Factor out the test if a
given symbol file is a module-definition (.def) file into...
(func_dll_def_p): ...this function, which also improves the check.
m4/libtool.m4 (_LT_LINKER_SHLIBS, _LT_LANG_CXX_CONFIG)
cygwin, mingw, pw32, cegcc: Similarly, factor out the test if
a given symbol file is a module-definition (.def) file into...
(_LT_DLL_DEF_P): ...this macro, which also improves the check.
tests/export-def.at: New test.
Makefile.am (TESTSUITE_AT): Add above test.
NEWS: Update.
THANKS: Update.
Signed-off-by: Peter Rosin p...@lysator.liu.se
# Conflicts:
#
# m4/libtool.m4
---
Makefile.am |1 +
NEWS|3 +
THANKS |2 +
build-aux/ltmain.in | 19 +++-
m4/libtool.m4 | 31 ---
tests/export-def.at | 139 +++
6 files changed, 186 insertions(+), 9 deletions(-)
create mode 100755 tests/export-def.at
diff --git a/Makefile.am b/Makefile.am
index a3e3c7d..e5f3805 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -627,6 +627,7 @@ TESTSUITE_AT= tests/testsuite.at \
tests/runpath-in-lalib.at \
tests/static.at \
tests/export.at \
+ tests/export-def.at \
tests/search-path.at \
tests/indirect_deps.at \
tests/archive-in-archive.at \
diff --git a/NEWS b/NEWS
index c202c43..514768b 100644
--- a/NEWS
+++ b/NEWS
@@ -66,6 +66,9 @@ NEWS - list of user-visible changes between releases of GNU
Libtool
the Microsoft Visual C/C++ linker via the -export-symbols argument to
the libtool script, thus matching how .def files are handled when
using GNU tools.
+ - Recognize more variants (e.g. those starting with a LIBRARY statement)
+of module-definitions (.def) files when using them instead of a raw
+list of symbols to export.
** Important incompatible changes:
diff --git a/THANKS b/THANKS
index d4c1f1b..92e6dff 100644
--- a/THANKS
+++ b/THANKS
@@ -98,6 +98,7 @@
Edouard G. Parmelan edouard.parme...@france.ncr.com
Erez Zadok e...@shekel.mcl.cs.columbia.edu
Eric Estievenart e...@via.ecp.fr
+ Erik van Pienbroek erik-...@vanpienbroek.nl
Ethan Malloveethan.mall...@sun.com
Frank Ch. Eigler f...@cygnus.com
Fred Cox sailorf...@yahoo.com
@@ -140,6 +141,7 @@
Marcel Loose lo...@astron.nl
Mark Ketteniskette...@phys.uva.nl
Markus Duft markus.d...@salomon.at
+ Martin Douchadou...@integri.cz
Matthijs Kooijmanmatth...@stdin.nl
Micheal E. Faenzamfae...@mitre.org
Michael Haubenwallnermichael.haubenwall...@salomon.at
diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index eb224e3..f0168da 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -1316,6 +1316,23 @@ func_convert_path_nix_to_cygwin ()
# end func_convert_path_nix_to_cygwin
+# func_dll_def_p FILE
+# True iff FILE is a Windows DLL '.def' file.
+# Keep in sync with _LT_DLL_DEF_P in libtool.m4
+func_dll_def_p ()
+{
+ $debug_cmd
+
+ func_dll_def_p_tmp=`$SED -n \
+-e 's/^[ ]*//' \
+-e '/^\(;.*\)*$/d' \
+-e 's/^\(EXPORTS\|LIBRARY\)\([ ].*\)*$/DEF/p' \
+-e q \
+$1`
+ test DEF = $func_dll_def_p_tmp
+}
+
+
# func_mode_compile arg...
func_mode_compile ()
{
@@ -7572,7 +7589,7 @@ EOF
cygwin* | mingw* | cegcc*)
if test -n $export_symbols test -z $export_symbols_regex; then
# exporting using user supplied symfile
- if test EXPORTS != `$SED 1q $export_symbols`; then
+ if ! func_dll_def_p $export_symbols; 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.
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 4bc9e98..0a6c334 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -3530,6 +3530,21 @@ _LT_DECL([], [MANIFEST_TOOL], [1], [Manifest tool])dnl
])# _LT_PATH_MANIFEST_TOOL
+# _LT_DLL_DEF_P([FILE])
+# -
+# True iff FILE is a Windows DLL '.def' file.
+# Keep in sync with func_dll_def_p in the libtool script
+AC_DEFUN([_LT_DLL_DEF_P],
+[dnl
+ test DEF = `$SED -n dnl
+-e '\''s/^[[ ]]*//'\'' dnl Strip leading whitespace
+-e '\''/^\(;.*\)*$/d'\'' dnl Delete empty lines and comments
+-e '\''s/^\(EXPORTS\|LIBRARY\)\([[ ]].*\)*$/DEF/p'\'' dnl
+-e q dnl Only consider the first real line
+$1` dnl
+])# _LT_DLL_DEF_P
+
+
# LT_LIB_M
#
# check for math library
@@ -4782,9 +4797,9 @@ _LT_EOF
if $LD --help 21 | $GREP
Re: bug#13414: Valid DLL def file mangled by libtool
Hi Peter, Thanks for working on this. On 19 Jan 2013, at 05:55, Peter Rosin p...@lysator.liu.se wrote: On 2013-01-12 01:26, Peter Rosin wrote: On 2013-01-11 12:34, Martin Doucha wrote: I'd like to report a bug in libtool 2.4 (including the latest git revision) which mangles valid DLL def files under MinGW and makes the linker barf. This issue has been reported before [1]. So, as hinted above, I'm following up with a pair of patches that appear to mend this. Ok to push? By inspection, these patches look good to me - presuming there are no regressions, please go ahead. One nit: your new test has a Copyright notice starting at 2007 followed by written in 2013. The new code doesn't look derivative of existing tests, so I'd suggest deleting the years prior to 2013 before pushing. Or are the white-space changes in the first patch too intrusive? If you would like to separate those into a separate patch then please feel free; but I'd rather see functional progress in Libtool development than being overly anal about changeset minutiae for potential future git archaeology at the expense of using your Libtool hacking time more wisely :) Cheers, -- Gary V. Vaughan (gary AT gnu DOT org)
