Re: rcs-5.7.96 build feedback
Thien-Thi Nguyen <[email protected]> Sun, 23 Jan 2011 16:20:56 +0100
| Newsgroups | gmane.comp.version-control.rcs.bugs |
|---|---|
| Message-ID | <[email protected]> |
() "Nelson H. F. Beebe" <[email protected]> () Sat, 22 Jan 2011 16:18:17 -0700 (MST) I have a test lab of about 25 flavors of Unix on all of the major CPU architectures. Builds and validations of rcs-5.7.96 have been successful on GNU/Linux, Mac OS X, FreeBSD, and NetBSD systems. Cool, thanks for evaluating 5.7.96. Recently, 5.7.97 became available, so i would be very interested in finding out how that fares in your lab. However, there are build or test failures on several others. Here is a problem summary: OK, ready! ------------------------------------------------------------------------ SGI IRIX MIPS No C99 compiler available. I suppose we could try to relax the C99 compiler requirement (falling back to C89) but this platform is such a low priority, i don't see it realistically happening for RCS 5.8. Nonetheless, the issue is recorded: <https://savannah.gnu.org/bugs/?32215>, should someone wish to invest some effort in the future. ------------------------------------------------------------------------ Solaris 10 AMD64: gcc -std=gnu99 -std=gnu99 -DHAVE_CONFIG_H -I. -I../lib -I'../lib' -D_REENTRANT -g -O2 -MT b-feph.o -MD -MP -MF .deps/b-feph.Tpo -c -o b-feph.o b-feph.c b-feph.c: In function `init_ephemstuff': b-feph.c:171: error: prior parameter's size depends on 'count' This error message mystifies me. I see on line 171 the static func ‘reap’, which has an arglist that includes ‘count’: 170 static void 171 reap (size_t count, struct sff all[count], 172 int (*cut) (char const *filename)) but the error message (1) names the wrong function; and (2) says "prior parameter" when ‘sff’ is declared after (left to right). Could this be a bug in the compiler? ------------------------------------------------------------------------ Solaris 10 AMD64 or SPARC: Compilation with "gcc-4.2.4 -std=gnu99" succeeds, but all tests fail: ./t010: syntax error at line 21: `(' unexpected FAIL: t010 ./t030: syntax error at line 21: `(' unexpected FAIL: t030 ... Changing SHELL to /bin/ksh, /bin/bash, /usr/local/bin/bash, etc does not help. I suspect this is because that shell's ‘case’ statement does not support a pattern starting with open paren, like: case x in (x) echo ok ;; esac # should be ok, but i see not everywhere In the test suite such phrasing has now been converted to omit the open paren: <http://git.savannah.gnu.org/cgit/rcs.git/commit/?id=f5bb5f4d99>. For the record, this was one of those warnings i read but did not heed (info "(autoconf) Limitations of Builtins") -- let my blunderings here serve as an example! ------------------------------------------------------------------------ Solaris 10 AMD64 SPARC: /usr/local/bin/gcc-4.3 -std=c99 -DHAVE_CONFIG_H -I. -I../lib -I'../lib' -D_REENTRANT -g -O2 -MT merger.o -MD -MP -MF .deps/merger.Tpo -c -o merger.o merger.c merger.c: In function 'merge': merger.c:98: error: 'label' undeclared (first use in this function) merger.c:98: error: (Each undeclared identifier is reported only once merger.c:98: error: for each function it appears in.) Brain fade, fixed in repo: <http://git.savannah.gnu.org/cgit/rcs.git/commit/?id=4b654e581b>. I wonder what is a good way to incorporate testing for different configure results (such as ‘!DIFF3_BIN’ in this case). ------------------------------------------------------------------------ MirBSD IA-32: /usr/bin/mgcc -std=gnu99 -std=gnu99 -DHAVE_CONFIG_H -I. -I../lib -I'../lib' -I/usr/local/include -MT b-isr.o -MD -MP -MF .deps/b-isr.Tpo -c -o b-isr.o b-isr.c b-isr.c: In function `scratch_from_context': b-isr.c:119: error: structure has no member named `uc_stack' ------------------------------------------------------------------------ OpenBSD IA-32: /usr/bin/cc -std=gnu99 -std=gnu99 -DHAVE_CONFIG_H -I. -I../lib -I'../lib' -I/usr/local/include -MT b-isr.o -MD -MP -MF .deps/b-isr.Tpo -c -o b-isr.o b-isr.c b-isr.c: In function `scratch_from_context': b-isr.c:119: error: structure has no member named `uc_stack' I don't know what to do about these -- my understanding is that ‘struct ucontext_t’ should have member ‘uc_stack’. Could you please send me manpages for sigaction(2), setcontext(2) and getcontext(2) for these systems? ------------------------------------------------------------------------ OpenSolaris 11 AMD64 with /bin/c99: Build succeeds, but 11 tests fail: FAIL: t160 FAIL: t510 FAIL: t511 FAIL: t600 FAIL: t601 FAIL: t603 FAIL: t604 FAIL: t605 FAIL: t606 FAIL: t900 FAIL: t999 ------------------------------------------------------------------------ OpenSolaris 11 AMD64 with /bin/cc: Build succeeds, but 8 tests fail: FAIL: t600 FAIL: t601 FAIL: t603 FAIL: t604 FAIL: t605 FAIL: t606 FAIL: t900 FAIL: t999 On that system, a build with /usr/sfw/bin/gcc (3.4.3) passes all tests. Could you please send me a tarball of the build tree, if it's not too heavy (for my ISP)? If it's too heavy, i would appreciate seeing specifically: config.log config.status tests/*.d/* # that is, all files in the t???.d/ directories # preserved for improperly behaving tests plus a log of "make all check". I look forward to any info you can provide, including a similar evaluation of 5.7.97, towards a cleaner 5.8 release. Thanks again.