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's not a workable solution. The normal configure output and config.log were invented to do what Bob wants. Libtool cannot in general know what is important for the package, IMVHO. So if the functioning of a compiler is important, then configure should simply fail if the compiler does not work. I tend to agree with this, but the author of the package needs a way to know that libtool has failed to sufficiently configure and have a way to notify the user. Right now there is no documented way to know if libtool encountered problems during configuration. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ Bug-libtool mailing list [email protected] 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]
[[libtool-patches removed from Cc:]] On 6 Mar 2008, at 16:52, Ralf Wildenhues wrote: * Gary V. Vaughan wrote on Thu, Mar 06, 2008 at 10:41:47PM CET: On 6 Mar 2008, at 15:03, Bob Friesenhahn wrote: There needs to be a way to output any warnings at the tail end of configure so that at least someone is more likely to see them. Without adequate notification to the user, the user is likely to try 'make' and then find that libtool does not work. Oo! Oo! Add that to the libtool-2.4 roadmap! :-) FWIW, I don't think that's a good request. Let the package developer put at the end what she wants to. If we start automatizing duplicating messages in Libtool or Autoconf, then in a couple of years the number of such messages will be so large that somebody will scream: "let's put the *really* important messages once more *after that*!" That's not a workable solution. The normal configure output and config.log were invented to do what Bob wants. Libtool cannot in general know what is important for the package, IMVHO. So if the functioning of a compiler is important, then configure should simply fail if the compiler does not work. Good point. Although an LT_ macro to spew a diversion collecting libtool configure time warnings (or similar) to make it easy for developers to add a consistently formatted summary at the end of their configure.ac still seems like a nice idea to me. Cheers, Gary -- <=. Email me: [EMAIL PROTECTED] / @ @ /| Read my blog: http://blog.azazil.net \ \\ ...and my book: http://sources.redhat.com/autobook \^^\\ PGP.sig Description: This is a digitally signed message part ___ Bug-libtool mailing list [email protected] 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]
* Gary V. Vaughan wrote on Thu, Mar 06, 2008 at 10:41:47PM CET: > On 6 Mar 2008, at 15:03, Bob Friesenhahn wrote: >> There needs to be a way to output any warnings at the tail end of >> configure so that at least someone is more likely to see them. >> Without adequate notification to the user, the user is likely to try >> 'make' and then find that libtool does not work. > Oo! Oo! Add that to the libtool-2.4 roadmap! :-) FWIW, I don't think that's a good request. Let the package developer put at the end what she wants to. If we start automatizing duplicating messages in Libtool or Autoconf, then in a couple of years the number of such messages will be so large that somebody will scream: "let's put the *really* important messages once more *after that*!" That's not a workable solution. The normal configure output and config.log were invented to do what Bob wants. Libtool cannot in general know what is important for the package, IMVHO. So if the functioning of a compiler is important, then configure should simply fail if the compiler does not work. Cheers, Ralf ___ Bug-libtool mailing list [email protected] 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]
Hi Bob, On 6 Mar 2008, at 15:03, Bob Friesenhahn wrote: There needs to be a way to output any warnings at the tail end of configure so that at least someone is more likely to see them. Without adequate notification to the user, the user is likely to try 'make' and then find that libtool does not work. Oo! Oo! Add that to the libtool-2.4 roadmap! :-) If I find time, I'll refactor the pages at http://wiki.azazil.net/GnuLibtoolProject/ToDo and http://wiki.azazil.net/GnuLibtoolProject/RoadMap To help us manage what we want to put in the next major release. Cheers, Gary -- ())_. Email me: [EMAIL PROTECTED] ( '/ Read my blog: http://blog.azazil.net / )= ...and my book: http://sources.redhat.com/autobook `(_~)_ PGP.sig Description: This is a digitally signed message part ___ Bug-libtool mailing list [email protected] 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 Thu, 6 Mar 2008, Peter O'Gorman wrote: What would be ideal is to check that the compiler exists, is executable, works (an possibly, when not cross-compiling, test that trivial code that is compiled with the compiler runs) but not cause an error if the compiler is broken or does not exist, simply warn the user that a broken compiler was detected and set the same vars in the same way as would be set if no compiler was detected. I agree with most of this (ammended for cross-compile) except that it is wrong to assume that users watch configure output while it runs. Most people seem to use that time to get a cup of coffee (or another Canadian beer). There needs to be a way to output any warnings at the tail end of configure so that at least someone is more likely to see them. Without adequate notification to the user, the user is likely to try 'make' and then find that libtool does not work. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ Bug-libtool mailing list [email protected] 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]
Ralf Wildenhues wrote: > * Bob Friesenhahn wrote on Thu, Mar 06, 2008 at 08:43:15PM CET: >> On Thu, 6 Mar 2008, Peter O'Gorman wrote: >>> I think the test for a working GCJ should be in libtool, and unset GCJ, >>> avoid adding the tag etc.if it is found to be nonfunctional. We would >>> have to issue a warning during configure or something. Does not look to >>> be quite as easy as this patch though, if you want to apply this one as >>> a stop-gap measure, that is fine. > > I'm considering doing that (the stop-gap measure). Your call. > Yes, and I can conceive just as well a libtool-using package which may > optionally use a Java compiler, and thus its configure script should not > bail out at Libtool's whim either. I agree, the way LT_LANG has worked so far is to test if a compiler for the language exists and is executable (or something similar), but not cause an error if it does not. What would be ideal is to check that the compiler exists, is executable, works (an possibly, when not cross-compiling, test that trivial code that is compiled with the compiler runs) but not cause an error if the compiler is broken or does not exist, simply warn the user that a broken compiler was detected and set the same vars in the same way as would be set if no compiler was detected. Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list [email protected] 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 Thu, 6 Mar 2008, Ralf Wildenhues wrote: But that should not be Libtool's decision, but the package's. Libtool already supports a syntax by which the package can specify the languages that it wants to configure for. I agree that this may not be expected to cause hard-failure if a language is found to not work. So it seems that we need a way to specify both the languages to try to configure for, and the ones that must work. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ Bug-libtool mailing list [email protected] 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 08:43:15PM CET: > On Thu, 6 Mar 2008, Peter O'Gorman wrote: >> I think the test for a working GCJ should be in libtool, and unset GCJ, >> avoid adding the tag etc.if it is found to be nonfunctional. We would >> have to issue a warning during configure or something. Does not look to >> be quite as easy as this patch though, if you want to apply this one as >> a stop-gap measure, that is fine. I'm considering doing that (the stop-gap measure). > If libtool is integrated into a package and the package declares that it > needs a Java compiler, then failure to pass basic tests should cause > configure to quit with an error (similar to the way configure fails if > the C compiler does not work). But that should not be Libtool's decision, but the package's. > If libtool is built stand-alone (as in > our distribution) then there should be a warning but the user should > still be able to build and install libtool. Yes, and I can conceive just as well a libtool-using package which may optionally use a Java compiler, and thus its configure script should not bail out at Libtool's whim either. Cheers, Ralf ___ Bug-libtool mailing list [email protected] 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 Thu, 6 Mar 2008, Peter O'Gorman wrote: I think the test for a working GCJ should be in libtool, and unset GCJ, avoid adding the tag etc.if it is found to be nonfunctional. We would have to issue a warning during configure or something. Does not look to be quite as easy as this patch though, if you want to apply this one as a stop-gap measure, that is fine. If libtool is integrated into a package and the package declares that it needs a Java compiler, then failure to pass basic tests should cause configure to quit with an error (similar to the way configure fails if the C compiler does not work). If libtool is built stand-alone (as in our distribution) then there should be a warning but the user should still be able to build and install libtool. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ Bug-libtool mailing list [email protected] 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]
Ralf Wildenhues wrote: > Hello Nelson, Peter, > > * Peter O'Gorman wrote on Thu, Mar 06, 2008 at 06:18:42AM CET: >> Nelson H. F. Beebe wrote: >> >>> libtool: compile: gcj -g -O2 -c A3.java >>> gcj: libgcj.spec: No such file or directory > >> Your gcj and automake are broken. Do you have a sane toolchain on any of >> your systems? > > First off, let us thank Nelson for doing all this testing work for us. > Thank you! Yes, thank you Nelson. > > Then, let's avoid us getting blame for broken gcj installations. > OK to apply this patch to avoid the gcj test when a compile would fail? > Or do you feel tests for working compilers should be done in configure > already? > I think the test for a working GCJ should be in libtool, and unset GCJ, avoid adding the tag etc.if it is found to be nonfunctional. We would have to issue a warning during configure or something. Does not look to be quite as easy as this patch though, if you want to apply this one as a stop-gap measure, that is fine. > Cheers, > Ralf > > 2008-03-06 Ralf Wildenhues <[EMAIL PROTECTED]> > > * tests/convenience.at (Java convenience archives): Skip test if > gcj cannot compile a .java file. > Report by Nelson H. F. Beebe. Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list [email protected] 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 Thu, 6 Mar 2008, Ralf Wildenhues wrote: Then, let's avoid us getting blame for broken gcj installations. OK to apply this patch to avoid the gcj test when a compile would fail? Or do you feel tests for working compilers should be done in configure already? My feeling is that the sooner a fundamental problem with a compiler is found, the better, so it makes sense to adequately sanity-check all compilers that libtool is configured for in the configure script. If the compiler does not pass a basic sanity check, then libtool should not support the associated language tag. If the package specifies that it needs that language, then configure should quit with an error. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ Bug-libtool mailing list [email protected] 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]
Hello Nelson,
* Nelson H. F. Beebe wrote on Thu, Mar 06, 2008 at 02:18:18AM CET:
> # -*- compilation -*-
> 35. am-subdir.at:33: testing ...
> libtoolize: putting auxiliary files in `.'.
> libtoolize: copying file `./ltmain.sh'
> libtoolize: putting macros in `m4'.
> libtoolize: copying file `m4/libtool.m4'
> libtoolize: copying file `m4/ltoptions.m4'
> libtoolize: copying file `m4/ltsugar.m4'
> libtoolize: copying file `m4/ltversion.m4'
> libtoolize: copying file `m4/lt~obsolete.m4'
> ./am-subdir.at:78: $ACLOCAL -I m4
> stderr:
> /usr/local/share/aclocal/yacc.m4:6: warning: underquoted definition of
> AM_PROG_YACC
> /usr/local/share/aclocal/yacc.m4:6: run info '(automake)Extending aclocal'
> /usr/local/share/aclocal/yacc.m4:6: or see
> http://sources.redhat.com/automake/automake.html#Extending-aclocal
> stdout:
> ./am-subdir.at:78: $AUTOMAKE --add-missing
> stderr:
> configure.ac:5: installing `./compile'
> configure.ac:3: installing `./config.sub'
> configure.ac:2: installing `./missing'
> configure.ac:2: installing `./install-sh'
> configure.ac:3: installing `./config.guess'
> Makefile.am: installing `./depcomp'
> 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
> stdout:
> ./am-subdir.at:78: exit code was 255, 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)
Could it be possible that, on your system,
/usr/local/share/automake-1.10/Automake/Channels.pm
is from Automake 1.10.1, but
/usr/local/bin/automake
is from Automake 1.10? If so, how did you manage to get it that way?
It would explain this failure.
Thanks,
Ralf
___
Bug-libtool mailing list
[email protected]
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]
Hello Nelson, Peter,
* Peter O'Gorman wrote on Thu, Mar 06, 2008 at 06:18:42AM CET:
> Nelson H. F. Beebe wrote:
>
> > libtool: compile: gcj -g -O2 -c A3.java
> > gcj: libgcj.spec: No such file or directory
> Your gcj and automake are broken. Do you have a sane toolchain on any of
> your systems?
First off, let us thank Nelson for doing all this testing work for us.
Thank you!
Then, let's avoid us getting blame for broken gcj installations.
OK to apply this patch to avoid the gcj test when a compile would fail?
Or do you feel tests for working compilers should be done in configure
already?
Cheers,
Ralf
2008-03-06 Ralf Wildenhues <[EMAIL PROTECTED]>
* tests/convenience.at (Java convenience archives): Skip test if
gcj cannot compile a .java file.
Report by Nelson H. F. Beebe.
Index: tests/convenience.at
===
RCS file: /cvsroot/libtool/libtool/tests/convenience.at,v
retrieving revision 1.8
diff -u -r1.8 convenience.at
--- tests/convenience.at25 Mar 2007 12:12:43 - 1.8
+++ tests/convenience.at6 Mar 2008 19:05:17 -
@@ -1,6 +1,6 @@
# convenience.at -- testing C convenience archives-*- Autotest -*-
-# Copyright (C) 2005, 2007 Free Software Foundation, Inc.
+# Copyright (C) 2005, 2007, 2008 Free Software Foundation, Inc.
# Written by Ralf Wildenhues, 2005
#
# This file is part of GNU Libtool.
@@ -258,6 +258,14 @@
public A$i () { a = 0; }
};
EOF
+
+ # There are just too many broken gcj installations out there, either missing
+ # libgcj.spec or unable to find it. Skip this test for them.
+ if test $i -eq 1; then
+AT_CHECK[($GCJ $GCJFLAGS -c foo1.java || exit 77], [], [ignore], [ignore])
+rm -f foo1.o foo1.obj
+ fi
+
$LIBTOOL --tag=GCJ --mode=compile $GCJ $GCJFLAGS -c foo$i.java
$LIBTOOL --tag=GCJ --mode=compile $GCJ $GCJFLAGS -c A$i.java
$LIBTOOL --tag=GCJ --mode=link $GCJ $GCJFLAGS $LDFLAGS -o liba$i.la A$i.lo
___
Bug-libtool mailing list
[email protected]
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 6 Mar 2008, at 02:05, Bob Friesenhahn wrote: 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). Libtool was bootstrapped using Automake-1.10.1, but there is no reason that users of Libtool-2.2 need to use it too. I was careful to build the lzma release files by hand to compensate for not offering xdeltas or diffs -- and didn't introduce a dependency on the lzma rules to libtool-2.2 so that compatibility with older Automakes wasn't compromised. The reported error message seems quite strange, particularly since LZMA is in caps. I agree with Peter's diagnosis... Nelson's Automake installation seews broken somehow: that's a perl failure in the Automake code AFAICT. The reported errors occur when am-subdir.at run Nelson's automake (which is at least version 1.10, judging by the log messages. Cheers, Gary -- ())_. Email me: [EMAIL PROTECTED] ( '/ Read my blog: http://blog.azazil.net / )= ...and my book: http://sources.redhat.com/autobook `(_~)_ PGP.sig Description: This is a digitally signed message part ___ Bug-libtool mailing list [email protected] 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 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-libtool
