Re: [PPL-devel] [libtool 2.2] testsuite: 34 failed
Ralf Wildenhues wrote:
- Roberto Bagnara wrote on Sun, Mar 02, 2008 at 08:48:07AM CET:
I got errors on a Fedora 7 system (x86_64): the log file is attached. I have also tried using Libtool 2.2 on one of my projets, but I get the following:
/bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I.. -I/home/roberto/ppl/ppl/src -I.. -I/home/roberto/ppl/ppl/src -g -frounding-math -W -Wall -MT Box.lo -MD -MP -MF .deps/Box.Tpo -c -o Box.lo /home/roberto/ppl/ppl/src/Box.cc ../libtool: line 459: CDPATH: command not found ../libtool: line 1262: func_opt_split: command not found libtool: Version mismatch error. This is libtool 2.2, but the libtool: definition of this LT_INIT comes from an older release. libtool: You should recreate aclocal.m4 with macros from libtool 2.2 libtool: and run autoconf again.
I think I did that on entirely new directories and after running `autoreconf -f' to recreate (among other things), aclocal.m4. What am I missing?
Which Autoconf, M4 versions were used? What says grep LT_INIT aclocal.m4 m4/libtool.m4
(modify the latter to point at the libtool.m4 file that's copied into your project if any).
Hi Ralf,
this was entirely my fault: I did something stupid in my first attempt of switching from Libtool 1.5.24 to Libtool 2.2 (m4/libtool.m4 was not even there).
However, things still do not seem to work properly for me. Trying to understand what is going on, I have distilled the following:
$ cat mycommand #!/bin/sh echo "mycommand invoked with argument '$1'" $ mycommand ciao mycommand invoked with argument 'ciao' $ ./libtool --mode=execute mycommand ciao mycommand invoked with argument '/home/roberto/tppl/' $
Note that /home/roberto/tppl/ is the directory where the libtool script is located. I can also do
$ cd interfaces/ $ ../libtool --mode=execute ../mycommand ciao mycommand invoked with argument '/home/roberto/tppl/'
Is this behavior normal? ./libtool is what has been created at configure time and a bzipped version of it is attached to this file.
Still looking at your the testsuite failure (but it's anyway an issue separate from the above).
Cheers, and thanks for the report,
Thanks to you! Best,
Roberto
P.S. In ./libtool there is the line
# Generated automatically by config.status (GNU ppl) 0.10pre16
`ppl' is indeed the short name of the project. I don't know why it is preceded by "GNU".
* Roberto Bagnara wrote on Mon, Mar 03, 2008 at 09:14:48PM CET:
P.S. In ./libtool there is the line
# Generated automatically by config.status (GNU ppl) 0.10pre16 `ppl' is indeed the short name of the project. I don't know why it is preceded by "GNU".
Fixed with the patch below. I don't care much that, in the Libtool package itself, the will result in a libtool script with the line # Generated automatically by config.status (libtool 1.2600 2008/03/02 02:19:16) 2.3a
instead of GNU libtool.
This has been reported several times, please speak up if I forgot to mention a reporter. The hard part with this patch was ensuring that none of the libtool code uses this bit in a sed pattern (in some parts script headers are checked, but not this one, apparently).
Cheers, and thanks to both of you for the report (I put you in THANKS), Ralf
2008-03-04 Ralf Wildenhues Ralf.Wildenhues@gmx.de
* libltdl/m4/libtool.m4 (_LT_CONFIG): Drop misleading `GNU' prefix before the host package name in the "Generated by" line for the libtool script. * THANKS: Update. Reports by Peter Rosin and Roberto Bagnara.
Index: libltdl/m4/libtool.m4 =================================================================== RCS file: /cvsroot/libtool/libtool/libltdl/m4/libtool.m4,v retrieving revision 1.137 diff -u -r1.137 libtool.m4 --- libltdl/m4/libtool.m4 20 Feb 2008 20:11:39 -0000 1.137 +++ libltdl/m4/libtool.m4 4 Mar 2008 21:11:56 -0000 @@ -685,7 +685,7 @@ #! $SHELL
# `$ECHO "$ofile" | sed 's%^.*/%%'` - Provide generalized library-building support services. -# Generated automatically by $as_me (GNU $PACKAGE$TIMESTAMP) $VERSION +# Generated automatically by $as_me ($PACKAGE$TIMESTAMP) $VERSION # Libtool was configured on host `(hostname || uname -n) 2>/dev/null | sed 1q`: # NOTE: Changes made to this file will be lost: look at ltmain.sh. #
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
According to Ralf Wildenhues on 3/4/2008 2:14 PM: | Fixed with the patch below. I don't care much that, in the Libtool | package itself, the will result in a libtool script with the line | # Generated automatically by config.status (libtool 1.2600 2008/03/02 02:19:16) 2.3a | | instead of GNU libtool.
Hmm. While this avoids the bug, I'm not sure if it was the best fix.
| # `$ECHO "$ofile" | sed 's%^.*/%%'` - Provide generalized library-building support services. | -# Generated automatically by $as_me (GNU $PACKAGE$TIMESTAMP) $VERSION | +# Generated automatically by $as_me ($PACKAGE$TIMESTAMP) $VERSION
TIMESTAMP is a libtool invention, and is not documented in autoconf or automake as a typical variable. At one point, M4 also tried using it, by parsing the CVS revision from ChangeLog, but ever since m4 switched to git, that aspect is broken (besides, I like what autoconf has achieved with intra-release versioning via the git-version-gen script). Can we expect reasonable semantics from TIMESTAMP in all other libtoolized packages, if we don't document it? Meanwhile, is there one of the Autoconf-provided variables, such as PACKAGE_NAME, which might fit better (and in the case of libtool, preserve the name 'GNU libtool')?
- -- Don't work too hard, make some time for fun as well!
Eric Blake ebb9@byu.net
Hi Eric,
* Eric Blake wrote on Wed, Mar 05, 2008 at 04:28:51AM CET:
According to Ralf Wildenhues on 3/4/2008 2:14 PM: | Fixed with the patch below. I don't care much that, in the Libtool | package itself, the will result in a libtool script with the line | # Generated automatically by config.status (libtool 1.2600 2008/03/02 02:19:16) 2.3a | | instead of GNU libtool.
Hmm. While this avoids the bug, I'm not sure if it was the best fix.
Granted, it's certainly debatable. IMHO it's a strict improvement over what we had before, though.
| # `$ECHO "$ofile" | sed 's%^.*/%%'` - Provide generalized library-building support services. | -# Generated automatically by $as_me (GNU $PACKAGE$TIMESTAMP) $VERSION | +# Generated automatically by $as_me ($PACKAGE$TIMESTAMP) $VERSION
TIMESTAMP is a libtool invention, and is not documented in autoconf or automake as a typical variable. At one point, M4 also tried using it, by parsing the CVS revision from ChangeLog, but ever since m4 switched to git, that aspect is broken (besides, I like what autoconf has achieved with intra-release versioning via the git-version-gen script). Can we expect reasonable semantics from TIMESTAMP in all other libtoolized packages, if we don't document it? Meanwhile, is there one of the Autoconf-provided variables, such as PACKAGE_NAME, which might fit better (and in the case of libtool, preserve the name 'GNU libtool')?
PACKAGE_NAME is currently not 'GNU libtool' for Libtool, also PACKAGE_NAME is currently not available inside config.status (FWIW, I feel that the fact that libtool even makes $PACKAGE available in config.status is an ugly hack and a layering violation; OTOH you should be able to decide at m4 time whether what we're bootstrapping is Libtool or some third-party package).
Changing PACKAGE for the Libtool package requires somebody to audit all code that matches comments in .lo and .la files and so on. If TIMESTAMP is empty because we are in a third party package, the above line has no problem. The exact timestamp and version of the Libtool used for libtoolizing the third-party package is anyway found further down in the libtool file, after the variable settings:
# Generated from ltmain.m4sh.
# ltmain.sh (GNU libtool 1.2600 2008/03/02 02:19:16) 2.3a
So frankly, the only thing that may be bothering at all is the missing 'GNU ' for the /usr/bin/libtool script which comes from the Libtool package, and that TIMESTAMP may need adjusting when we move to git. I let somebody motivated enough work on fixing the first, and will cross the bridge for the second when I get to it.
Cheers, Ralf
Hello Roberto,
* Roberto Bagnara wrote on Mon, Mar 03, 2008 at 09:14:48PM CET:
$ cat mycommand #!/bin/sh echo "mycommand invoked with argument '$1'" $ mycommand ciao mycommand invoked with argument 'ciao' $ ./libtool --mode=execute mycommand ciao mycommand invoked with argument '/home/roberto/tppl/' $
Note that /home/roberto/tppl/ is the directory where the libtool script is located. I can also do
$ cd interfaces/ $ ../libtool --mode=execute ../mycommand ciao mycommand invoked with argument '/home/roberto/tppl/'
Is this behavior normal?
No. Thank you for the bug report. I've applied the fix below.
FWIW, the ordering of the tests in execute-mode.at is such that the first set still passes for 1.5.26.
./libtool is what has been created at configure time and a bzipped version of it is attached to this file.
It wasn't attached to the message, but that's not a problem. :-)
Cheers, Ralf
* libltdl/config/ltmain.m4sh (func_mode_execute): Replace only arguments we have identified as shell or C wrappers. (func_emit_wrapper): Output error message on stderr. * tests/execute-mode.at: New file, with --mode=execute tests. * Makefile.am: Adjust. * NEWS: Update. Fixes 2.2 regression. Report by Roberto Bagnara.
Index: Makefile.am =================================================================== RCS file: /cvsroot/libtool/libtool/Makefile.am,v retrieving revision 1.229 diff -u -r1.229 Makefile.am --- Makefile.am 18 Jan 2008 10:49:40 -0000 1.229 +++ Makefile.am 4 Mar 2008 21:16:26 -0000 @@ -447,6 +447,7 @@ tests/search-path.at \ tests/indirect_deps.at \ tests/archive-in-archive.at \ + tests/execute-mode.at \ tests/destdir.at \ tests/old-m4-iface.at \ tests/am-subdir.at \ Index: NEWS =================================================================== RCS file: /cvsroot/libtool/libtool/NEWS,v retrieving revision 1.220 diff -u -r1.220 NEWS --- NEWS 4 Mar 2008 21:00:18 -0000 1.220 +++ NEWS 4 Mar 2008 21:16:27 -0000 @@ -6,6 +6,9 @@
- Fix 2.2 regression in libltdl that causes memory corruption upon repeated `lt_dlinit(); lt_dlexit()'. + - Fix 2.2 regression in that `libtool --mode=execute CMD ARGS' does not + transform ARGS that do not look like shell or C wrappers of libtool + programs.
New in 2.2: 2008-03-01; CVS version 2.1c, Libtool team:
Index: libltdl/config/ltmain.m4sh =================================================================== RCS file: /cvsroot/libtool/libtool/libltdl/config/ltmain.m4sh,v retrieving revision 1.97 diff -u -r1.97 ltmain.m4sh --- libltdl/config/ltmain.m4sh 28 Jan 2008 15:49:46 -0000 1.97 +++ libltdl/config/ltmain.m4sh 4 Mar 2008 21:16:29 -0000 @@ -1694,12 +1694,14 @@ # Do a test to see if this is really a libtool program. if func_ltwrapper_script_p "$file"; then func_source "$file" + # Transform arg to wrapped name. + file="$progdir/$program" elif func_ltwrapper_executable_p "$file"; then func_ltwrapper_scriptname "$file" func_source "$func_ltwrapper_scriptname_result" + # Transform arg to wrapped name. + file="$progdir/$program" fi - # Transform arg to wrapped name. - file="$progdir/$program" ;; esac # Quote arguments (to preserve shell metacharacters). @@ -2468,7 +2470,7 @@ ;; esac $ECHO "\ - $ECHO "$0: cannot exec $program $*" + $ECHO "$0: cannot exec $program $*" 1>&2 exit 1 fi else --- /dev/null 2008-03-02 10:33:19.200041011 +0100 +++ tests/execute-mode.at 2008-03-04 22:15:22.000000000 +0100 @@ -0,0 +1,92 @@ +# execute-mode.at -- libtool --mode=execute -*- Autotest -*- +# +# Copyright (C) 2008 Free Software Foundation, Inc. +# Written by Ralf Wildenhues, 2008 +# +# This file is part of GNU Libtool. +# +# GNU Libtool is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# GNU Libtool is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with GNU Libtool; see the file COPYING. If not, a copy +# can be downloaded from http://www.gnu.org/licenses/gpl.html, +# or obtained by writing to the Free Software Foundation, Inc., +# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. +#### + +AT_SETUP([execute mode]) +AT_KEYWORDS([libtool]) + +AT_DATA([foo], +[[#! /bin/sh +if test $# -gt 0; then + echo "$@" +else + : +fi +]]) + +AT_DATA([lt-wrapper], +[[#! /bin/sh +# Generated by GNU libtool. +# fake wrapper script. +program=lt-real +progdir=. +if test "$libtool_execute_magic" != "%%%MAGIC variable%%%"; then + # Run the actual program with our arguments. + exec "$progdir/$program" ${1+"$@"} + echo "$0: cannot exec $program $*" >&2 + exit 1 +fi +]]) + +AT_DATA([lt-real], +[[#! /bin/sh +echo "$@" +]]) + +mkdir sub +cp foo sub/foo +chmod +x foo sub/foo lt-wrapper lt-real + +AT_CHECK([$LIBTOOL --mode=execute ./foo]) +AT_CHECK([$LIBTOOL --mode=execute sub/foo]) +AT_CHECK([$LIBTOOL --mode=execute ./foo foo], [], [foo +]) +AT_CHECK([$LIBTOOL --mode=execute ./lt-wrapper foo], [], [foo +]) +AT_CHECK([cd sub && $LIBTOOL --mode=execute ./foo ../foo], [], [../foo +]) +# suppose that ./foo is gdb, and lt-wrapper is the wrapper script. +AT_CHECK([$LIBTOOL --mode=execute ./foo lt-wrapper bar baz], [], + [./lt-real bar baz +]) + +# Check that a missing real program causes an error. +# The error message and code are likely to be 126, +# "No such file or directory" but system-dependent. +mv -f lt-real lt-backup +AT_CHECK([$LIBTOOL --mode=execute ./lt-wrapper foo || exit 1], + [1], [ignore], [ignore]) +mv -f lt-backup lt-real + +# Now use arguments that require decent quoting. +AT_CHECK([$LIBTOOL --mode=execute ./foo "arg with special chars: $!&*`'()"], + [], [arg with special chars: $!&*`'() +]) +AT_CHECK([$LIBTOOL --mode=execute ./lt-wrapper "arg with special chars: $!&*`'()"], + [], [arg with special chars: $!&*`'() +]) +AT_CHECK([$LIBTOOL --mode=execute ./foo lt-wrapper "arg with special chars: $!&*`'()"], + [], [./lt-real arg with special chars: $!&*`'() +]) + +AT_CLEANUP
Ralf Wildenhues wrote:
- Roberto Bagnara wrote on Mon, Mar 03, 2008 at 09:14:48PM CET:
$ cat mycommand #!/bin/sh echo "mycommand invoked with argument '$1'" $ mycommand ciao mycommand invoked with argument 'ciao' $ ./libtool --mode=execute mycommand ciao mycommand invoked with argument '/home/roberto/tppl/' $
Note that /home/roberto/tppl/ is the directory where the libtool script is located. I can also do
$ cd interfaces/ $ ../libtool --mode=execute ../mycommand ciao mycommand invoked with argument '/home/roberto/tppl/'
Is this behavior normal?
No. Thank you for the bug report. I've applied the fix below.
FWIW, the ordering of the tests in execute-mode.at is such that the first set still passes for 1.5.26.
./libtool is what has been created at configure time and a bzipped version of it is attached to this file.
Thanks a lot Ralf!
It is better now, but there is still the problem that, apparently, libtool redirects stdin for the program it is running. Here is a new testcase:
$ cat mycommand #!/bin/sh echo "mycommand invoked with argument '$1' '$2' '$3' '$4' '$5'" while read line do echo "$line" done $ /bin/sh ../../../libtool --mode=execute \ -dlopen ../../../src/libppl.la \ -dlopen ../../../Watchdog/src/libpwl.la \ mycommand mycommand invoked with argument '' '' '' '' '' # # Please DO NOT delete this file! # It is necessary for linking the library.
# The name that we can dlopen(3). dlname='libpwl.so.4'
# Names of this library. library_names='libpwl.so.4.0.0 libpwl.so.4 libpwl.so'
# The name of the static archive. old_library='libpwl.a'
# Linker flags that can not go in dependency_libs. inherited_linker_flags=''
# Libraries that this one depends upon. dependency_libs=''
# Names of additional weak libraries provided by this library weak_library_names=''
# Version information for libpwl. current=4 age=0 revision=0
# Is this an already installed library? installed=no
# Should we warn about portability when linking against -modules? shouldnotlink=no
# Files to dlopen/dlpreopen dlopen='' dlpreopen=''
# Directory that this library needs to be installed in: libdir='/usr/local/lib' $ /bin/sh ../../../libtool --mode=execute \ -dlopen ../../../src/libppl.la \ -dlopen ../../../Watchdog/src/libpwl.la \ mycommand >produced_by_mycommand $ diff produced_by_mycommand ../../../Watchdog/src/libpwl.la 1c1,2 < mycommand invoked with argument '' '' '' '' '' ---
# libpwl.la - a libtool library file # Generated by ltmain.sh (GNU libtool) 2.2
$
It wasn't attached to the message, but that's not a problem. :-)
You are right. It happens to me all the time :-) Let me know if you need it this time. Cheers,
Roberto
* Roberto Bagnara wrote on Wed, Mar 05, 2008 at 07:37:58AM CET:
It is better now, but there is still the problem that, apparently, libtool redirects stdin for the program it is running.
Gosh. How embarrassing. I've applied this patch.
Thanks for testing! Ralf
2008-03-05 Ralf Wildenhues Ralf.Wildenhues@gmx.de
* libltdl/config/ltmain.m4sh (func_lalib_unsafe_p): redirect and restore from stdin, not stdout. * tests/execute-mode.at (execute mode): Adjust test to catch this. Report by Roberto Bagnara.
Index: libltdl/config/ltmain.m4sh =================================================================== RCS file: /cvsroot/libtool/libtool/libltdl/config/ltmain.m4sh,v retrieving revision 1.98 diff -u -r1.98 ltmain.m4sh --- libltdl/config/ltmain.m4sh 4 Mar 2008 21:25:48 -0000 1.98 +++ libltdl/config/ltmain.m4sh 5 Mar 2008 20:12:28 -0000 @@ -648,7 +648,7 @@ func_lalib_unsafe_p () { lalib_p=no - if test -r "$1" && exec 5<&1 <"$1"; then + if test -r "$1" && exec 5<&0 <"$1"; then for lalib_p_l in 1 2 3 4 do read lalib_p_line @@ -656,7 +656,7 @@ #\ Generated\ by\ *$PACKAGE* ) lalib_p=yes; break;; esac done - exec 1<&5 5<&- + exec 0<&5 5<&- fi test "$lalib_p" = yes } Index: tests/execute-mode.at =================================================================== RCS file: /cvsroot/libtool/libtool/tests/execute-mode.at,v retrieving revision 1.1 diff -u -r1.1 execute-mode.at --- tests/execute-mode.at 4 Mar 2008 21:25:48 -0000 1.1 +++ tests/execute-mode.at 5 Mar 2008 20:12:28 -0000 @@ -51,6 +51,30 @@ AT_DATA([lt-real], [[#! /bin/sh echo "$@" +cat +]]) + +AT_DATA([libfakelib.la], +[[# libfakelib.la - a libtool library file +# Generated by ltmain.sh (GNU libtool 1.2605 2008/03/04 22:31:32) 2.3a +# +# Please DO NOT delete this file! +# It is necessary for linking the library. + +dlname='' +library_names='' +old_library='libfakelib.a' +inherited_linker_flags='' +dependency_libs='' +weak_library_names='' +current= +age= +revision= +installed=no +shouldnotlink=yes +dlopen='' +dlpreopen='' +libdir='' ]])
mkdir sub @@ -61,20 +85,26 @@ AT_CHECK([$LIBTOOL --mode=execute sub/foo]) AT_CHECK([$LIBTOOL --mode=execute ./foo foo], [], [foo ]) -AT_CHECK([$LIBTOOL --mode=execute ./lt-wrapper foo], [], [foo +AT_CHECK([$LIBTOOL --mode=execute ./lt-wrapper foo </dev/null], [], [foo ]) AT_CHECK([cd sub && $LIBTOOL --mode=execute ./foo ../foo], [], [../foo ]) # suppose that ./foo is gdb, and lt-wrapper is the wrapper script. -AT_CHECK([$LIBTOOL --mode=execute ./foo lt-wrapper bar baz], [], +AT_CHECK([$LIBTOOL --mode=execute ./foo lt-wrapper bar baz </dev/null], [], [./lt-real bar baz ])
+# check that stdin works even with -dlopen. +AT_CHECK([echo bar | $LIBTOOL --mode=execute -dlopen libfakelib.la ./lt-wrapper foo], + [], [foo +bar +]) + # Check that a missing real program causes an error. # The error message and code are likely to be 126, # "No such file or directory" but system-dependent. mv -f lt-real lt-backup -AT_CHECK([$LIBTOOL --mode=execute ./lt-wrapper foo || exit 1], +AT_CHECK([$LIBTOOL --mode=execute ./lt-wrapper foo </dev/null || exit 1], [1], [ignore], [ignore]) mv -f lt-backup lt-real
@@ -82,7 +112,7 @@ AT_CHECK([$LIBTOOL --mode=execute ./foo "arg with special chars: $!&*`'()"], [], [arg with special chars: $!&*`'() ]) -AT_CHECK([$LIBTOOL --mode=execute ./lt-wrapper "arg with special chars: $!&*`'()"], +AT_CHECK([$LIBTOOL --mode=execute ./lt-wrapper "arg with special chars: $!&*`'()" </dev/null], [], [arg with special chars: $!&*`'() ]) AT_CHECK([$LIBTOOL --mode=execute ./foo lt-wrapper "arg with special chars: $!&*`'()"],
Ralf Wildenhues wrote:
- Roberto Bagnara wrote on Wed, Mar 05, 2008 at 07:37:58AM CET:
It is better now, but there is still the problem that, apparently, libtool redirects stdin for the program it is running.
Gosh. How embarrassing. I've applied this patch.
Dear Ralf,
everything seems to work for us now. Thanks!
Roberto
P.S. I will look at the testsuite failure during the weekend.
participants (3)
-
Eric Blake -
Ralf Wildenhues -
Roberto Bagnara