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/
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
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/
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/
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
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/
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
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
