Re: [GNU Autoconf 2.68] testsuite: 205 failed
On 09/23/2010 07:03 AM, Ralf Wildenhues wrote: Hello Ralf, thanks for the bug report. * Ralf Corsepius wrote on Thu, Sep 23, 2010 at 06:31:47AM CEST: autoconf-2.68's testsuite deterministically fails for me in test 205 for a variety of OSes: ... 205: parallel autotest and signal handling FAILED (autotest.at:1617) Yeah, it's the test that is broken, not Autotest. The bug is known. Sorry, I didn't manage to get it fixed in time for 2.68. Thanks. This is what I had assume and wanted to hear ;) I am going to temporarily disable this check. FWIW, the test wrongly assumes that the output crosses a pipe buffer boundary and thus elicits a SIGPIPE, which is simply not true on some systems. Some? It fails on all Linux distros, I've tried ;) Ralf
Re: autoconf-2.68: test 199 hangs under Cygwin
On 09/23/2010 01:03 AM, Ralf Corsepius wrote: Hi, I just gave autoconf-2.68 a try under Cygwin. Is this supposed to work rsp. does this work for anybody? Cygwin has known bugs with named pipes, and they are so severe that autotest parallel tests are known to fail on that platform. There's nothing autoconf can do about it until cygwin's pipe implementation is fixed. For me, autoconf-2.68's testsuite seems to hang in test 199, after having emitting several FAILEDs on preceeding tests. Which tests? -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org
Re: [GNU Autoconf 2.68] testsuite: 205 failed
On 09/22/2010 10:31 PM, Ralf Corsepius wrote: ... 205: parallel autotest and signal handling FAILED (autotest.at:1617) ... * Fedora 12/13/14 i386/x86_64 * RHEL6 beta2 i386/x86_64 Odd, because I specifically tested under these two, and it passed for me. Is there an environmental difference between our two setups, such as an inherited ignored SIGPIPE setup in the test environment? Remember, POSIX states that a shell that inherits ignored SIGPIPE at startup cannot undo that effect (which is rather annoying). From what I can gather, it's the killer test which fails: Not quite, it's the point at which the testsuite.log shows a diff in expected vs. actual output. The killer test is supposed to fail, and the real failure is occurring later in the log. But Ralf Wildenhues' analysis is correct - the test is making a bad assumption about what scenarios will cause a SIGPIPE, and if SIGPIPE doesn't actually happen, then the test gets confused and fails. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org
Re: autoconf-2.68: test 199 hangs under Cygwin
On 09/23/2010 06:07 AM, Eric Blake wrote: On 09/23/2010 01:03 AM, Ralf Corsepius wrote: Hi, I just gave autoconf-2.68 a try under Cygwin. Is this supposed to work rsp. does this work for anybody? Cygwin has known bugs with named pipes, and they are so severe that autotest parallel tests are known to fail on that platform. There's nothing autoconf can do about it until cygwin's pipe implementation is fixed. Unless you can find a quickie shell test that validates whether the named pipe implementation is buggy and can thus skip parallel testing on cygwin in the first place (I haven't yet found such a test that rules out cygwin but without hanging). We already have other quickie tests, like whether set -m works, whether mkfifo works and whether trap ... STOP works; but the problem is all three of those work on cygwin. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org
Re: autoconf-2.68: test 199 hangs under Cygwin
On 09/23/2010 02:07 PM, Eric Blake wrote: On 09/23/2010 01:03 AM, Ralf Corsepius wrote: Hi, I just gave autoconf-2.68 a try under Cygwin. Is this supposed to work rsp. does this work for anybody? Cygwin has known bugs with named pipes, and they are so severe that autotest parallel tests are known to fail on that platform. There's nothing autoconf can do about it until cygwin's pipe implementation is fixed. For me, autoconf-2.68's testsuite seems to hang in test 199, When rerunning the testsuite, ... test 199 has completed. Checking tests/testsuite.log tells: 199. parallel test execution (autotest.at:1371): ok (0m57.333s 1m3.784s) after having emitting several FAILEDs on preceeding tests. Which tests? Several, but I don't have any real testsuites results, yet, because the testsuite still hasn't completed, yet. Typing the failed ons off from the terminal: 38 40 81 101 147 166 183 195 202 No further results, because the testsuite now hangs in test 203. Ralf
Re: [GNU Autoconf 2.68] testsuite: 205 failed
On 09/23/2010 02:11 PM, Eric Blake wrote: On 09/22/2010 10:31 PM, Ralf Corsepius wrote: ... 205: parallel autotest and signal handling FAILED (autotest.at:1617) ... * Fedora 12/13/14 i386/x86_64 * RHEL6 beta2 i386/x86_64 Odd, because I specifically tested under these two, and it passed for me. Is there an environmental difference between our two setups, Likely - As with previous reports I sent on 2.67, I am actually building autoconf rpms in mock chroots on Fedora 13/x86_64. such as an inherited ignored SIGPIPE setup in the test environment? Remember, POSIX states that a shell that inherits ignored SIGPIPE at startup cannot undo that effect (which is rather annoying). From what I can gather, it's the killer test which fails: Not quite, it's the point at which the testsuite.log shows a diff in expected vs. actual output. The killer test is supposed to fail, and the real failure is occurring later in the log. But Ralf Wildenhues' analysis is correct - the test is making a bad assumption about what scenarios will cause a SIGPIPE, and if SIGPIPE doesn't actually happen, then the test gets confused and fails. OK. Ralf
Re: autoconf-2.68: test 199 hangs under Cygwin
On 09/23/2010 02:14 PM, Eric Blake wrote: On 09/23/2010 06:07 AM, Eric Blake wrote: On 09/23/2010 01:03 AM, Ralf Corsepius wrote: Hi, I just gave autoconf-2.68 a try under Cygwin. Is this supposed to work rsp. does this work for anybody? Cygwin has known bugs with named pipes, and they are so severe that autotest parallel tests are known to fail on that platform. There's nothing autoconf can do about it until cygwin's pipe implementation is fixed. Unless you can find a quickie shell test that validates whether the named pipe implementation is buggy and can thus skip parallel testing on cygwin in the first place (I haven't yet found such a test that rules out cygwin but without hanging). We already have other quickie tests, like whether set -m works, whether mkfifo works and whether trap ... STOP works; but the problem is all three of those work on cygwin. I recall older versions of autoconf under older Cygwins having had problems with some process related resources and people being recommended to increase some of them. If so, which and how? I am only very infrequently using Cygwin and Windows in general, so I don't recall the details and am more or less a completely illiterate about Cygwin. Ralf
autoconf-2.68: no AC_LANG_SOURCE call detected in body
Hi, I am facing a new issue/regression with autoconf-2.68: When running autoreconf on the follow configure.ac[1] -- snip -- AC_INIT([foo],[0.1]) AC_CONFIG_SRCDIR([configure.ac]) AM_INIT_AUTOMAKE([foreign]) AC_COMPILE_IFELSE([ #ifndef FOO choke me #endif ]) AC_CONFIG_FILES([Makefile]) AC_OUTPUT -- snip -- autoconf-2.68 complains: # autoreconf -fi autoreconf -fi configure.ac:6: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2591: _AC_COMPILE_IFELSE is expanded from... ../../lib/autoconf/general.m4:2607: AC_COMPILE_IFELSE is expanded from... configure.ac:6: the top level configure.ac:6: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2591: _AC_COMPILE_IFELSE is expanded from... ../../lib/autoconf/general.m4:2607: AC_COMPILE_IFELSE is expanded from... configure.ac:6: the top level configure.ac:6: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2591: _AC_COMPILE_IFELSE is expanded from... ../../lib/autoconf/general.m4:2607: AC_COMPILE_IFELSE is expanded from... configure.ac:6: the top level configure.ac:6: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2591: _AC_COMPILE_IFELSE is expanded from... ../../lib/autoconf/general.m4:2607: AC_COMPILE_IFELSE is expanded from... configure.ac:6: the top level With older autoconfs, autoreconf remains entirely silent. What is wrong with this configure.ac rsp. how to overcome these warnings? Ralf [1] I actually tripped this issue with a real world package. The configure.ac above is a stripped version of a much more complex real world configure script.
Re: autoconf-2.68: no AC_LANG_SOURCE call detected in body
On 09/23/2010 06:56 AM, Ralf Corsepius wrote: Hi, I am facing a new issue/regression with autoconf-2.68: That is not a regression, but a feature. Reread NEWS: AC_COMPILE_IFELSE([ #ifndef FOO choke me #endif ]) You should have used: AC_COMPILE_IFELSE([AC_LANG_SOURCE([ #ifndef FOO choke me #endif ]) With older autoconfs, autoreconf remains entirely silent. Not only were they entirely silent, but most likely generated a broken configure. If you don't use AC_LANG_SOURCE, then you don't get the benefit of all the prior AC_DEFINEs being implicitly included before the body of your test, which leads to documented cases of mis-diagnosing whether a feature is present for a given build. What is wrong with this configure.ac rsp. how to overcome these warnings? Use AC_LANG_SOURCE, like the warning told you to do in the first place. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org
Re: autoconf-2.68: no AC_LANG_SOURCE call detected in body
On 09/23/2010 07:52 AM, Eric Blake wrote: [hit send too soon] On 09/23/2010 06:56 AM, Ralf Corsepius wrote: Hi, I am facing a new issue/regression with autoconf-2.68: That is not a regression, but a feature. Reread NEWS: ** The macros AC_PREPROC_IFELSE, AC_COMPILE_IFELSE, AC_LINK_IFELSE, and AC_RUN_IFELSE now warn if the first argument failed to use AC_LANG_SOURCE or AC_LANG_PROGRAM to generate the conftest file contents. A new macro AC_LANG_DEFINES_PROVIDED exists if you have a compelling reason why you cannot use AC_LANG_SOURCE but must avoid the warning. AC_COMPILE_IFELSE([ #ifndef FOO choke me #endif ]) You should have used: AC_COMPILE_IFELSE([AC_LANG_SOURCE([ #ifndef FOO choke me #endif ]) Needs another ]), to match the fact that there is an added ([ from the added call to AC_LANG_SOURCE. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org
Re: autoconf-2.68: no AC_LANG_SOURCE call detected in body
On 09/23/2010 03:52 PM, Eric Blake wrote: On 09/23/2010 06:56 AM, Ralf Corsepius wrote: Hi, I am facing a new issue/regression with autoconf-2.68: That is not a regression, but a feature. Your feature is my regression - It broke what appeared to have worked for ages ;) Reread NEWS: AC_COMPILE_IFELSE([ #ifndef FOO choke me #endif ]) You should have used: AC_COMPILE_IFELSE([AC_LANG_SOURCE([ #ifndef FOO choke me #endif ]) OK, thanks. With older autoconfs, autoreconf remains entirely silent. Not only were they entirely silent, but most likely generated a broken configure. If you don't use AC_LANG_SOURCE, then you don't get the benefit of all the prior AC_DEFINEs being implicitly included before the body of your test, which leads to documented cases of mis-diagnosing whether a feature is present for a given build. Actually, I don't need the AC_DEFINES in this particular case - Adding them however, should not do much harm, either. What is wrong with this configure.ac rsp. how to overcome these warnings? Use AC_LANG_SOURCE, like the warning told you to do in the first place. Well, really usable warnings look a bit different than this warning. They might be self-explanatory to you, but to me this warning was Greek. Ralf
Re: autoconf-2.68: no AC_LANG_SOURCE call detected in body
* Ralf Corsepius wrote on Thu, Sep 23, 2010 at 04:33:01PM CEST: On 09/23/2010 03:52 PM, Eric Blake wrote: On 09/23/2010 06:56 AM, Ralf Corsepius wrote: I am facing a new issue/regression with autoconf-2.68: That is not a regression, but a feature. Your feature is my regression - It broke what appeared to have worked for ages ;) Beside the fact that the warning might be a false positive in your case, can you please confirm that it was only a warning, and did not actually *break* the resulting configure script, right? Without autoconf -Werror, things should have still worked as expected. Well, really usable warnings look a bit different than this warning. They might be self-explanatory to you, but to me this warning was Greek. That's a QoI issue (and of course always good and important to improve upon) but not a regression. Thanks, Ralf
Re: [GNU Autoconf 2.68] testsuite: 199 205 261 262 failed
Hi Scott, * scott mc wrote on Thu, Sep 23, 2010 at 06:41:30PM CEST: This was on Haiku, gcc2 build, r38734,IIRC this is similar to the results for autoconf 2.67 on Haiku. Thanks for the bug report. Can you try this patch to see whether it fixes the failures of 261 and 262 for you? It should suffice to run make check TESTSUITEFLAGS=--recheck or make check TESTSUITEFLAGS=261-262 Please send 'gcc2 --version' output. Thanks, Ralf tests: normalize trailing spaces in gcc -E -dD output. * tests/compile.at (AC_LANG_SOURCE example) (AC_LANG_PROGRAM example): Remove trailing spaces before comparing with expected output. Fixes testsuite failure with GCC X.Y on Haiku. Report by Scott McCreary. diff --git a/tests/compile.at b/tests/compile.at index dd7175b..7af76b1 100644 --- a/tests/compile.at +++ b/tests/compile.at @@ -193,7 +193,7 @@ AT_CHECK_CONFIGURE([], [], [stdout]) # Note that the output may contain more defines and lines matching # # 1 conftest.c # so delete everything before the interesting output. -AT_CHECK([sed -n '/#define PACKAGE/,$p' stdout], [], +AT_CHECK([sed -n 's/ *$//; /#define PACKAGE/,$p' stdout], [], [[#define PACKAGE_NAME Hello #define PACKAGE_TARNAME hello #define PACKAGE_VERSION 1.0 @@ -238,7 +238,7 @@ AT_CHECK_CONFIGURE([], [], [stdout]) # Note that the output may contain more defines and lines matching # # 1 conftest.c # so delete everything before the interesting output. -AT_CHECK([sed -n '/#define PACKAGE/,$p' stdout], [], +AT_CHECK([sed -n '/s/ *$//; #define PACKAGE/,$p' stdout], [], [[#define PACKAGE_NAME Hello #define PACKAGE_TARNAME hello #define PACKAGE_VERSION 1.0
