Re: mode=execute argument munging bug
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 -- 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
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 \$*\" 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.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/
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
Re: libltdl memory corruption
Hi Peter, * Peter O'Gorman wrote on Tue, Mar 04, 2008 at 07:14:51AM CET: > Ralf Wildenhues wrote: > > > > So I'd appreciate a review of this, and also test results on systems > > with loaders other than preopen and dlopen. (I haven't even tested > > successful compilation on those other systems.) > > I did not manage to try the shl_load loader, only tested dyld. This > patch causes no regressions on Mac OS X 10.2. If that is also true for > the loaders you get around to trying, this is ok. For the preopen, dlopen, shl_load loaders, I confirmed that the testsuite addition exposes the bug, and the loader changes fixes the testsuite failure. For loadlibrary, I only cross-compiled from GNU/Linux to ensure absense of typos. I visually inspected the BeOS and dld changes again for typos, and then applied the patch, after adding a NEWS entry. > Thank you. Once again you sent a patch for a bug before I even got > around to reading the list. My pleasure. :-) Kudos to Andreas for reporting the bug. Cheers, Ralf ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: Another powerpc64 biarch problem.
Steven Munroe wrote: > On Sat, 2008-03-01 at 09:39 -0600, Peter O'Gorman wrote: >> Steven Munroe wrote: >>> I am trying to build a package on a OpenSuse-10.3 PowerMac G5. and I see >>> the following: >>> >>> /bin/sh ../../libtool --tag=CC --mode=link /usr/bin/gcc -m64 -g -O2 >>> -mcpu=power >>> 4 -fno-strict-aliasing -Wdeclaration-after-statement -g -Wall -Wunused >>> -Wmissing >>> -prototypes -Wmissing-declarations -Wstrict-prototypes >>> -Wmissing-prototypes -Wn >>> ested-externs -Wpointer-arith -Wno-cast-qual -Wcast-align >>> -Wwrite-strings -m64 >>> -o pedump pedump.o >>> libmonoruntime.la ../io-layer/libwapi.la ../utils/libmonouti >>> ls.la ../../libgc/libmonogc.la -pthread -lgthread-2.0 -lrt -lglib-2.0 >>> -lm -ldl >>> -lpthread -lm >>> libtool: link: cannot find the library `/usr/lib64/libpcre.la' >>> or unhandled argument `/usr/lib64/libpcre.la' >> It seems likely that some other .la file has /usr/lib64/libpcre.la in >> its dependency_libs. If you add --debug immediately prior to the >> --tag=CC and save stdout and stderr to a log, reading the log should >> tell you which one. Alternatively, grep for /usr/lib64/libpcre.la in >> /usr/lib64. > > The dependency seem to be coming from /usr/lib64/libgthread-2.0.la at > least on the system that is failing. The older (--debug output -> > libtool-libpcre-ok.tgz) system does not seem to have the same > dependency. > > I still don't understand why libtool does not simply link to > the /usr/lib64/libpcre.so that is there? > > This is really annoying... Both libgthread and libglib have /usr/lib64/libpcre.la in dependency_libs, so this file must have existed when glib was built. Now it does not. Your choices are: 1) rebuild glib (when rebuilt without the presence of /usr/lib64/libpcre.la, that will not appear in dependency_libs) 2) rebuild/reinstall 64bit pcre (to get the .la file back) 3) edit the glib .la files by hand and change /usr/lib64/libpcre.la to -lpcre (ugly) Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: Another powerpc64 biarch problem.
On Sat, 2008-03-01 at 09:39 -0600, Peter O'Gorman wrote: > Steven Munroe wrote: > > I am trying to build a package on a OpenSuse-10.3 PowerMac G5. and I see > > the following: > > > > /bin/sh ../../libtool --tag=CC --mode=link /usr/bin/gcc -m64 -g -O2 > > -mcpu=power > > 4 -fno-strict-aliasing -Wdeclaration-after-statement -g -Wall -Wunused > > -Wmissing > > -prototypes -Wmissing-declarations -Wstrict-prototypes > > -Wmissing-prototypes -Wn > > ested-externs -Wpointer-arith -Wno-cast-qual -Wcast-align > > -Wwrite-strings -m64 > > -o pedump pedump.o > > libmonoruntime.la ../io-layer/libwapi.la ../utils/libmonouti > > ls.la ../../libgc/libmonogc.la -pthread -lgthread-2.0 -lrt -lglib-2.0 > > -lm -ldl > > -lpthread -lm > > libtool: link: cannot find the library `/usr/lib64/libpcre.la' > > or unhandled argument `/usr/lib64/libpcre.la' > > It seems likely that some other .la file has /usr/lib64/libpcre.la in > its dependency_libs. If you add --debug immediately prior to the > --tag=CC and save stdout and stderr to a log, reading the log should > tell you which one. Alternatively, grep for /usr/lib64/libpcre.la in > /usr/lib64. The dependency seem to be coming from /usr/lib64/libgthread-2.0.la at least on the system that is failing. The older (--debug output -> libtool-libpcre-ok.tgz) system does not seem to have the same dependency. I still don't understand why libtool does not simply link to the /usr/lib64/libpcre.so that is there? This is really annoying... libtool-libpcre.tgz Description: application/compressed-tar libtool-libpcre-ok.tgz Description: application/compressed-tar ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
