Re: [libtool 2.2] testsuite: 19 35 36 44 45 46 48 49 50 51 52 53 60 61 62 64 failed [GNU/Linux PowerPC]
On Thu, 6 Mar 2008, Ralf Wildenhues wrote: That sounds a little harsh. I think that the LZMA complaint from automake may be because libtool requests a lzma package and it requires the very latest automake to do so. Where does Libtool 2.2 require lzma? That would be a serious bug, requiring such a recent Automake. I was not able to find where libtool 'requests' a lzma package but I do see that all of the Makefile.in files in the distribution include a target for it (dist-lzma). The reported error message seems quite strange, particularly since LZMA is in caps. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 19 35 36 44 45 46 48 49 50 51 52 53 60 61 62 64 failed [GNU/Linux PowerPC]
On Wed, 5 Mar 2008, Peter O'Gorman wrote: You are right, of course, it was too harsh. I was simply overwhelmed when I looked at the volume of mail on the bug-libtool list. You have no reason to be overwelmed. Just divide the volume of mail regarding 2.X by the four years it took to produce it. Then it seems fairly trivial. :-) Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ 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
Re: [libtool 2.2] testsuite: 19 35 36 44 45 46 48 49 50 51 52 53 60 61 62 64 failed [GNU/Linux PowerPC]
* Bob Friesenhahn wrote on Thu, Mar 06, 2008 at 06:28:10AM CET: > On Wed, 5 Mar 2008, Peter O'Gorman wrote: >> >> Your gcj and automake are broken. Do you have a sane toolchain on any of >> your systems? > > That sounds a little harsh. I think that the LZMA complaint from > automake may be because libtool requests a lzma package and it requires > the very latest automake to do so. Where does Libtool 2.2 require lzma? That would be a serious bug, requiring such a recent Automake. Thanks, Ralf ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 19 64 failed [GNU/Linux AMD64]
Nelson H. F. Beebe wrote: > /export/local/x86_64-linux/bin/../lib/gcc-lib/x86_64-unknown-linux-gnu/3.3.5/jc1: > error while loading shared libraries: libiconv.so.2: cannot open shared > object file: No such file or directory Problem with your gcj install and libiconv on this machine too. Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 19 64 failed [GNU/Linux Alpha]
Nelson H. F. Beebe wrote: > @@ -0,0 +1 @@ > +./main_static: error while loading shared libraries: libgcj.so.4: cannot > open shared object file: No such file or directory > ./convenience.at:277: exit code was 127, expected 0 > 19. convenience.at:229: 19. Java convenience archives (convenience.at:229): > FAILED (convenience.at:277) Your gcj on this system does not appear to add the runpath to libgcj when linking. Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 12 17 19 38 64 failed [Mac OS X Intel]
Nelson H. F. Beebe wrote: > ./duplicate_conv.at:81: $LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o main > main.$OBJEXT cee.$OBJEXT > stderr: > /usr/bin/ld: Undefined symbols: > _c > collect2: ld returned 1 exit status > stdout: > libtool: link: gcc -g -O2 -o main main.o cee.o > ./duplicate_conv.at:81: exit code was 1, expected 0 > 12. duplicate_conv.at:25: 12. duplicate convenience archive names > (duplicate_conv.at:25): FAILED (duplicate_conv.at:81) This one looks like my bad. Will look. Thanks. > /usr/bin/ld: /usr/local/lib/libf2c.a(main.o) malformed object (section > (__TEXT,__textcoal_nt) no symbol at start of coalesced section) > /usr/bin/ld: /usr/local/lib/libf2c.a(close.o) malformed object (section > (__TEXT,__textcoal_nt) no symbol at start of coalesced section) > /usr/bin/ld: /usr/local/lib/libf2c.a(err.o) malformed object (section > (__TEXT,__textcoal_nt) no symbol at start of coalesced section) > /usr/bin/ld: /usr/local/lib/libf2c.a(sig_die.o) malformed object (section > (__TEXT,__textcoal_nt) no symbol at start of coalesced section) > /usr/bin/ld: /usr/local/lib/libf2c.a(endfile.o) malformed object (section > (__TEXT,__textcoal_nt) no symbol at start of coalesced section) > /usr/bin/ld: /usr/local/lib/libf2c.a(open.o) malformed object (section > (__TEXT,__textcoal_nt) no symbol at start of coalesced section) > collect2: ld returned 1 exit status I must admit to not having tested on Mac OS X with fortran and java for a while, but this looks like a broken compiler. > gcj: libgcj.spec: No such file or directory > libtool: compile: gcj -g -O2 -c A3.java > gcj: libgcj.spec: No such file or directory So does this. I am now building gfortran, gcj etc on Mac OS X intel to make sure that things are working :) Thanks, Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 18 23 49 60 61 64 failed [OSF/1 Alpha]
Nelson H. F. Beebe wrote: > libtool: link: (cd .libs/liba12.lax/liba1.a && ar x > "/local/build/bare/libtool-2.2/tests/testsuite.dir/18/./.libs/liba1.a") > libtool: link: (cd .libs/liba12.lax/liba2.a && ar x > "/local/build/bare/libtool-2.2/tests/testsuite.dir/18/./.libs/liba2.a") > libtool: link: f95 -shared -expect_unresolved \* > .libs/liba12.lax/liba1.a/a1.o .libs/liba12.lax/liba2.a/a2.o -msym > -soname liba12.so.0 `test -n "0.0.0:0.0" && /usr/local/bin/echo > "X-set_version 0.0.0:0.0" | /usr/local/bin/sed -e 1s/^X//` -update_registry > .libs/so_locations -o .libs/liba12.so.0.0.0 > f95: Severe: Invalid file name - must be of the form name.suffix : * Ok, it really should not be using the results of the F77 checks to generate shared libraries for FC. We saw this with your solaris results too. > stderr: > stdout: > ./shlibpath.at:66: exit code was 1, expected 0 > 23. shlibpath.at:25: 23. shlibpath_overrides_runpath (shlibpath.at:25): > FAILED (shlibpath.at:66) > Hmm. We have access to an OSF1/Alpha system, so will look into this. > stdout: > ./nonrecursive.at:114: CONFIG_SHELL=$SHELL $SHELL ./configure > $configure_options > stderr: > ./config.status[672]: syntax error at line 775 : `newline or ;' unexpected That's strange! > stdout: > checking for a BSD-compatible install... /usr/local/bin/install -c > configure: error: C compiler cannot create executables > See `config.log' for more details. > And so is this. Thanks, Peter ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 33 34 35 36 44 45 46 48 49 50 51 52 53 57 58 60 61 62 failed [NetBSD IA-32]
Nelson H. F. Beebe wrote: > ./old-m4-iface.at:85: CONFIG_SHELL=$SHELL $SHELL ./configure > $configure_options > stderr: > stdout: > ./old-m4-iface.at:85: $MAKE > stderr: > make[4]: *** No targets specified and no makefile found. Stop. Hmm. 'CONFIG_SHELL=$SHELL $SHELL ./configure $configure_options' does not appear to do anything? I think Ralf has seen this before, if not I will look at it. Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 19 35 36 44 45 46 48 49 50 51 52 53 60 61 62 64 failed [GNU/Linux PowerPC]
Bob Friesenhahn wrote: > On Wed, 5 Mar 2008, Peter O'Gorman wrote: >> >> Your gcj and automake are broken. Do you have a sane toolchain on any of >> your systems? > > That sounds a little harsh. I think that the LZMA complaint from > automake may be because libtool requests a lzma package and it requires > the very latest automake to do so. Most people won't have the latest > automake. > > Libtool maintainers typically run all of the latest autotools in > relatively pristine environments. With so many tests, we can expect > plenty of breakage in more typical user environments. The test failures > don't mean that libtool won't satisfy the user's actual requirements. You are right, of course, it was too harsh. I was simply overwhelmed when I looked at the volume of mail on the bug-libtool list. Because of the lzma addition, an automake that is new enough to create lzma dists is required to run the testsuite. Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 19 64 failed [Solaris AMD64]
Nelson H. F. Beebe wrote: Hi Nelson, I admit that I don't understand the failures like this one yet. >> /convenience.at:265: $LIBTOOL --tag=GCJ --mode=link $GCJ $GCJFLAGS $LDFLAGS >> -o liba12.la liba1.la liba2.la -rpath /notexist >> stderr: >> stdout: >> libtool: link: gcj -shared -Wl,-z -Wl,text -Wl,-h -Wl,liba12.so.0 -o >> .libs/liba12.so.0.0.0 -Wl,-z -Wl,allextract ./.libs/liba1.a ./.libs/liba2.a >> -Wl,-z -Wl,defaultextract $GCJ is properly expanded to 'gcj' here. >> /convenience.at:267: $LIBTOOL --tag=GCJ --mode=link $GCJ $GCJFLAGS $LDFLAGS >> -o liba123.la A3.lo liba1.la liba2.la -rpath /notexist >> stderr: >> /local/build/bare/libtool-2.2/tests/testsuite.dir/64/libtool: line 7084: -r: >> command not found >> stdout: >> libtool: link: -r -o .libs/liba123.la-1.o .libs/A3.o But here it is the empty string! I'll look at it tomorrow. Thanks. Peter ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 19 35 36 44 45 46 48 49 50 51 52 53 60 61 62 64 failed [GNU/Linux PowerPC]
On Wed, 5 Mar 2008, Peter O'Gorman wrote: Your gcj and automake are broken. Do you have a sane toolchain on any of your systems? We should also keep in mind that autoconf apparently only checks the C compiler to verify that it is sane. There don't seem to be any good sanity checks for the C++, Java, or Fortran compilers. If the program is available we try to use it in the tests. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 19 64 failed [GNU/Linux IA-32]
Nelson H. F. Beebe wrote: > libtool: link: gcj -g -O2 --main=foo1 -o main_static .libs/foo1.o > ./.libs/liba1.a > +++ /local/build/bare/libtool-2.2/tests/testsuite.dir/at-stderr > 2008-03-04 15:26:49.0 -0700 > @@ -0,0 +1 @@ > +./main_static: error while loading shared libraries: libiconv.so.2: cannot > open shared object file: No such file or directory > ./convenience.at:277: exit code was 127, expected 0 > 19. convenience.at:229: 19. Java convenience archives (convenience.at:229): > FAILED (convenience.at:277) Hmm. Does the gcj on this system add -liconv at link time, but somehow not add it to the rpath? What does: gcj -### -o /dev/null /dev/null show? Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 19 35 36 44 45 46 48 49 50 51 52 53 60 61 62 64 failed [GNU/Linux PowerPC]
On Wed, 5 Mar 2008, Peter O'Gorman wrote: Your gcj and automake are broken. Do you have a sane toolchain on any of your systems? That sounds a little harsh. I think that the LZMA complaint from automake may be because libtool requests a lzma package and it requires the very latest automake to do so. Most people won't have the latest automake. Libtool maintainers typically run all of the latest autotools in relatively pristine environments. With so many tests, we can expect plenty of breakage in more typical user environments. The test failures don't mean that libtool won't satisfy the user's actual requirements. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 19 35 36 44 45 46 48 49 50 51 52 53 60 61 62 64 failed [GNU/Linux PowerPC]
Nelson H. F. Beebe wrote:
> libtool: compile: gcj -g -O2 -c A3.java
> gcj: libgcj.spec: No such file or directory
> automake:
> automake: ## Internal Error ##
> automake:
> automake: Unknown ?token? `LZMA' (neg = 0)
> automake: Please contact <[EMAIL PROTECTED]>.
> at /usr/local/share/automake-1.10/Automake/Channels.pm line 570
> Automake::Channels::msg('automake', '', 'Unknown ?token? `LZMA\' (neg =
> 0)') called at /usr/local/share/automake-1.10/Automake/ChannelDefs.pm line 191
> Automake::ChannelDefs::prog_error('Unknown ?token? `LZMA\' (neg = 0)')
> called at /usr/local/bin/automake line 6406
> Automake::transform('?LZMA?', 'HASH(0x104aa0d0)') called at
> /usr/local/bin/automake line 6469
>
> Automake::make_paragraphs('/usr/local/share/automake-1.10/am/distdir.am',
> 'GETTEXT', 0, 'DISTCHECK-HOOK', '', 'FILENAME_FILTER', '', 'DIST-TARGETS',
> '', ...) called at /usr/local/bin/automake line 6539
> Automake::file_contents_internal(1,
> '/usr/local/share/automake-1.10/am/distdir.am',
> 'Automake::Location=HASH(0x105b3d30)', 'DISTCHECK-HOOK', '', 'GETTEXT', 0,
> 'FILENAME_FILTER', '', ...) called at /usr/local/bin/automake line 6719
> Automake::file_contents('distdir',
> 'Automake::Location=HASH(0x105b3d30)', 'DIST-TARGETS', '', 'GETTEXT', 0,
> 'DISTCHECK-HOOK', '', 'FILENAME_FILTER', ...) called at
> /usr/local/bin/automake line 3688
> Automake::handle_dist() called at /usr/local/bin/automake line 7493
> Automake::generate_makefile('Makefile.am', 'Makefile.in') called at
> /usr/local/bin/automake line 7834
>
Your gcj and automake are broken. Do you have a sane toolchain on any of
your systems?
Peter
--
Peter O'Gorman
http://pogma.com
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 18 19 64 failed [Solaris 7 SPARC]
Nelson H. F. Beebe wrote: >> libtool: link: f90 -shared -Qoption ld --whole-archive ./.libs/liba1.a >> ./.libs/liba2.a -Qoption ld --no-whole-archive -Qoption ld -soname >> -Qoption ld liba12.so.0 -o .libs/liba12.so.0.0.0 >> /convenience.at:211: exit code was 1, expected 0 >> 18. convenience.at:169: 18. FC convenience archives (convenience.at:169): >> FAILED (convenience.at:211) Libtool detected FC as f90, but otherwise used the gcc tools. I'll look into this. >> libtool: compile: gcj -g -O2 -c A3.java >> A3.java:0: Can't find default package `java.lang'. Check the CLASSPATH >> environment variable and the access to the archives. Your gcj install is broken. Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 19 35 36 44 45 46 48 49 50 51 52 53 60 61 62 64 failed [Solaris IA-32]
Nelson H. F. Beebe wrote:
> ## --- ##
> ## libtool 2.2 test suite. ##
> ## --- ##
>
> testsuite: command line was:
> $ /local/build/bare/libtool-2.2/tests/testsuite MAKE=make CC=gcc CFLAGS=-g
> -O2 CPP=gcc -E CPPFLAGS= LD=/usr/ccs/bin/ld LDFLAGS= LIBS= LN_S=ln -s
> NM=/usr/local/bin/nm -B RANLIB=ranlib STRIP=strip OBJEXT=o EXEEXT=
> SHELL=/bin/bash CONFIG_SHELL=/bin/bash CXX=g++ CXXFLAGS=-g -O2 CXXCPP=g++ -E
> F77=g77 FFLAGS=-g -O2 FC=f95 FCFLAGS=-g GCJ=gcj GCJFLAGS=-g -O2
> _lt_pkgdatadir=/local/build/bare/libtool-2.2
> LIBTOOLIZE=/local/build/bare/libtool-2.2/libtoolize
> LIBTOOL=/local/build/bare/libtool-2.2/libtool
> tst_aclocaldir=/local/build/bare/libtool-2.2/libltdl/m4
>
> +++ /local/build/bare/libtool-2.2/tests/testsuite.dir/at-stderr
> 2008-03-04 15:36:24.883120064 -0700
> @@ -0,0 +1 @@
> +GC Warning: Large stack limit(133464064): only scanning 8 MB
> 19. convenience.at:229: 19. Java convenience archives (convenience.at:229):
> FAILED (convenience.at:277)
>
This stack limit warning caused the test to fail. Not pretty, but a bug
in the test, not in libtool itself.
> automake:
> automake: ## Internal Error ##
> automake:
> automake: Unknown ?token? `LZMA' (neg = 0)
> automake: Please contact <[EMAIL PROTECTED]>.
> at /usr/local/share/automake-1.10/Automake/Channels.pm line 570
> Automake::Channels::msg('automake', '', 'Unknown ?token? `LZMA\' (neg =
> 0)') called at /usr/local/share/automake-1.10/Automake/ChannelDefs.pm line 191
> Automake::ChannelDefs::prog_error('Unknown ?token? `LZMA\' (neg = 0)')
> called at /usr/local/bin/automake line 6406
> Automake::transform('?LZMA?', 'HASH(0x85404bc)') called at
> /usr/local/bin/automake line 6469
>
> Automake::make_paragraphs('/usr/local/share/automake-1.10/am/distdir.am',
> 'GETTEXT', 0, 'DISTCHECK-HOOK', '', 'FILENAME_FILTER', '', 'DIST-TARGETS',
> '', ...) called at /usr/local/bin/automake line 6539
> Automake::file_contents_internal(1,
> '/usr/local/share/automake-1.10/am/distdir.am',
> 'Automake::Location=HASH(0x8614194)', 'DISTCHECK-HOOK', '', 'GETTEXT', 0,
> 'FILENAME_FILTER', '', ...) called at /usr/local/bin/automake line 6719
> Automake::file_contents('distdir',
> 'Automake::Location=HASH(0x8614194)', 'DIST-TARGETS', '', 'GETTEXT', 0,
> 'DISTCHECK-HOOK', '', 'FILENAME_FILTER', ...) called at
> /usr/local/bin/automake line 3688
> Automake::handle_dist() called at /usr/local/bin/automake line 7493
> Automake::generate_makefile('Makefile.am', 'Makefile.in') called at
> /usr/local/bin/automake line 7834
> stdout:
> ./am-subdir.at:78: exit code was 2, expected 0
> ./am-subdir.at:78: grep 'require .*but have' stderr && (exit 77)
> 35. am-subdir.at:33: 35. C subdir-objects (am-subdir.at:33): FAILED
> (am-subdir.at:78)
There appears to be a problem with your automake install that is causing
most of these test failures.
Peter
--
Peter O'Gorman
http://pogma.com
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: mode=execute argument munging bug
* 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 <[EMAIL PROTECTED]>
* 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 - 1.98
+++ libltdl/config/ltmain.m4sh 5 Mar 2008 20:12:28 -
@@ -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 - 1.1
+++ tests/execute-mode.at 5 Mar 2008 20:12:28 -
@@ -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 http://lists.gnu.org/mailman/listinfo/bug-libtool
