Re: [libtool 2.2] testsuite: 34 failed
On Sat, Mar 08, 2008 at 09:58:38AM +0100, Roberto Bagnara wrote: Ralf Wildenhues wrote: What I instead meant was: the installed libltdl.la file is missing, but the libltdl.so.7 file is still present, as is the ltdl.h header in the include directory. Does that still match your setup? The problem is that I have installed 2.2 and then the versions patched as you indicated on the same path. So, even if something that belonged to 2.1.b was still there when I say 2.2's `make check' failing, now it has been overwritten. OK. Also, are things working for you with 2.3a now? Things work with 2.2 + your patches. However, I am of course willing to test with 2.3a. Where is it? I have looked in There is no release 2.3a. 2.3a is the term for the CVS version, i.e., currently CVS HEAD. There will however be a 2.2.2 in a few weeks. Just to make sure I have understood you right: if with whatever you currently have, you run make check-local TESTSUITEFLAGS=-v -d -x -k AC_WITH_LTDL then this passes for you now? Thanks, Ralf ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 34 failed
Ralf Wildenhues wrote: On Sat, Mar 08, 2008 at 09:58:38AM +0100, Roberto Bagnara wrote: Ralf Wildenhues wrote: What I instead meant was: the installed libltdl.la file is missing, but the libltdl.so.7 file is still present, as is the ltdl.h header in the include directory. Does that still match your setup? The problem is that I have installed 2.2 and then the versions patched as you indicated on the same path. So, even if something that belonged to 2.1.b was still there when I say 2.2's `make check' failing, now it has been overwritten. OK. Also, are things working for you with 2.3a now? Things work with 2.2 + your patches. However, I am of course willing to test with 2.3a. Where is it? I have looked in There is no release 2.3a. 2.3a is the term for the CVS version, i.e., currently CVS HEAD. There will however be a 2.2.2 in a few weeks. CVS HEAD passes all tests here and seem to work OK for our project. Just to make sure I have understood you right: if with whatever you currently have, you run make check-local TESTSUITEFLAGS=-v -d -x -k AC_WITH_LTDL then this passes for you now? Yes. Cheers, Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:[EMAIL PROTECTED] ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 34 failed
On Sat, Mar 08, 2008 at 08:27:38AM +0100, Roberto Bagnara wrote: Ralf Wildenhues wrote: I can reproduce this error under the following circumstances: A libltdl 2.1 or newer has previously been installed in a place where the preprocessor and the link editor can find headers resp. library (suitable CPPFLAGS=-I... and LDFLAGS=-L... count, too), but the libltdl.la file is missing in the installation, and also the runtime linker does not search the installed location of libltdl.so.7 by default (and -R.../-Wl,-rpath,... have not been added). Does that match your setup? If yes, who removed the installed libltdl.la file, and why? yes, I believe this matches my setup. I had installed Libtool 2.1.b; nothing worked for me so, since I had no time to investigate further, I uninstalled it (not the proper way, I guess) and went back to Libtool 1.5.24. But if you used make uninstall, then there should be no traces left. What I instead meant was: the installed libltdl.la file is missing, but the libltdl.so.7 file is still present, as is the ltdl.h header in the include directory. Does that still match your setup? Also, are things working for you with 2.3a now? Thanks, Ralf ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 34 failed
Hello Roberto,
your posts are good sources of bug reports ...
* Roberto Bagnara wrote on Sun, Mar 02, 2008 at 08:48:07AM CET:
## --- ##
## libtool 2.2 test suite. ##
## --- ##
[...]
## ##
## Summary of the failures. ##
## ##
Failed tests:
libtool 2.2 test suite test groups:
NUM: FILE-NAME:LINE TEST-GROUP-NAME
KEYWORDS
34: old-m4-iface.at:107 AC_WITH_LTDL
libtoolize automake autoconf
[...]
34. old-m4-iface.at:107: testing ...
libtoolize: putting auxiliary files in `.'.
[...]
checking whether libtool supports -dlopen/-dlpreopen... yes
checking for ltdl.h... yes
checking whether lt_dlinterface_register is declared... yes
checking for lt_dlinterface_register in -lltdl... yes
checking where to find libltdl headers...
checking where to find libltdl library... -lltdl
[...]
./old-m4-iface.at:153: $MAKE
[...]
/bin/sh ./libtool --mode=link gcc -no-undefined -g -O2 -o ltdldemo main.o
-dlopen module.la -lltdl
libtool: link: rm -f .libs/ltdldemo.nm .libs/ltdldemo.nmS .libs/ltdldemo.nmT
libtool: link: (cd .libs gcc -g -O2 -c -fno-builtin ltdldemoS.c)
libtool: link: rm -f .libs/ltdldemoS.c .libs/ltdldemo.nm
.libs/ltdldemo.nmS .libs/ltdldemo.nmT
libtool: link: gcc -g -O2 -o ltdldemo main.o .libs/ltdldemoS.o -lltdl
libtool: link: rm -f .libs/ltdldemoS.o
make[4]: Leaving directory
`/usr/local/distrib/libtool-2.2/tests/testsuite.dir/34'
./old-m4-iface.at:156: ./ltdldemo; lt_status=$?; if test $lt_status -eq 0;
then :;
elif test X$host != X$build \
{ test -x ./ltdldemo || test -x ./ltdldemo$EXEEXT; }
then (exit 77); else (exit $lt_status); fi
--- /dev/null 2008-02-27 15:51:00.483962769 +0100
+++ /usr/local/distrib/libtool-2.2/tests/testsuite.dir/at-stderr
2008-03-02 08:28:27.0 +0100
@@ -0,0 +1 @@
+./ltdldemo: error while loading shared libraries: libltdl.so.7: cannot open
shared object file: No such file or directory
stdout:
./old-m4-iface.at:156: exit code was 127, expected 0
34. old-m4-iface.at:107: 34. AC_WITH_LTDL (old-m4-iface.at:107): FAILED
(old-m4-iface.at:156)
I can reproduce this error under the following circumstances:
A libltdl 2.1 or newer has previously been installed in a place where
the preprocessor and the link editor can find headers resp. library
(suitable CPPFLAGS=-I... and LDFLAGS=-L... count, too), but the
libltdl.la file is missing in the installation, and also the runtime
linker does not search the installed location of libltdl.so.7 by
default (and -R.../-Wl,-rpath,... have not been added).
Does that match your setup? If yes, who removed the installed
libltdl.la file, and why?
Thanks,
Ralf
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool
libtool generated by GNU $PACKAGE (was: [libtool 2.2] testsuite: 34 failed)
* 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 [EMAIL PROTECTED] * 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 - 1.137 +++ libltdl/m4/libtool.m4 4 Mar 2008 21:11:56 - @@ -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. # ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
mode=execute argument munging bug (was: [libtool 2.2] testsuite: 34 failed)
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 - 1.229 +++ Makefile.am 4 Mar 2008 21:16:26 - @@ -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 --- NEWS4 Mar 2008 21:00:18 - 1.220 +++ NEWS4 Mar 2008 21:16:27 - @@ -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 - 1.97 +++ libltdl/config/ltmain.m4sh 4 Mar 2008 21:16:29 - @@ -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 \$*\ 12 exit 1 fi else --- /dev/null 2008-03-02 10:33:19.200041011 +0100 +++ tests/execute-mode.at 2008-03-04 22:15:22.0 +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
Re: [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. -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:[EMAIL PROTECTED] ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 34 failed
Hello Roberto, * 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). Still looking at your the testsuite failure (but it's anyway an issue separate from the above). Cheers, and thanks for the report, Ralf ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
