RE: Problems with getdate.y, compiling on HP-UX 11i

[SANTOS, DANIEL (SBCSI)]

buggy indeed. And just to be clear, here is the version info on the
bison I'm using and the same test that you showed:

$ bison -V
bison (GNU Bison) 1.875
Written by Robert Corbett and Richard Stallman.

Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
$ bison -y ./getdate.y ; echo $?
conflicts: 10 shift/reduce
141

Meanwhile, this is what yacc outputs:
$ yacc ./getdate.y ; echo $?

conflicts: 10 shift/reduce
0

I can't get yacc to spit out a version but the man page claims it's
"HP-UX Release 10.30:  May 1997" even though we have 11i( or B11.11).

My make also does not support any -V, --version, -version etc, but the
make man page claims "HP-UX Release 11i: November 2000". And I did
confirm that the dates are indeed identical and it's attempting to build
them anyway. The touch getdate.c also got me past this but the compiling
had this output:

        source='getdate.c' object='getdate.o' libtool=no \
        depfile='.deps/getdate.Po' tmpdepfile='.deps/getdate.TPo' \
        depmode=hp /bin/sh ../depcomp \
        /usr/bin/cc -DHAVE_CONFIG_H -I. -I. -I.. -I../src      -g -c
`test -f 'getdate.c' || echo './'`getdate.c
cc: "getdate.c", line 1094: warning 562: Redeclaration of
"getdate_yyparse" with a different storage class specifier:
"getdate_yyparse" will have internal linkage.

I already set an email to the bison bug list. I'm also submitting a bug
to HP via our sysadmins.

Daniel

-----Original Message-----
From: info-cvs-bounces+daniel.santos=pobox.com@gnu.org
[mailto:info-cvs-bounces+daniel.santos=pobox.com@gnu.org] On Behalf Of
Mark D. Baushke
Sent: Thursday, May 27, 2004 12:31 AM
To: SANTOS, DANIEL (SBCSI)
Cc: bug-cvs@gnu.org; info-cvs@gnu.org
Subject: Re: Problems with getdate.y, compiling on HP-UX 11i 


Hi Daniel,

First, it looks like HP/UX 11i has a buggy version of make.
The timestamps of getdate.y and getdate.c should be the same
in the cvs-1.11.16.tar.gz

-rw-r--r-- 500/500       44418 2004-02-03 06:37:49
cvs-1.11.16/lib/getdate.c
-rw-r--r-- 500/500       25566 2004-02-03 06:37:49
cvs-1.11.16/lib/getdate.y

and a conforming version of make should only rebuild the getdate.c file
if getdate.y is NEWER, not if they happen to have the same time. As a
workaround, I suspect that 'touch cvs-1.11.16/lib/getdate.c' is correct,
then make will not try to build getdate.c for you.

Second, the version of bison that has been tested with getdate.y to
generate getdate.c is bison 1.35. Newer versions are not necessarily
supported.

Third, when I run either bison 1.35 or bison 1.875 on the lib/getdate.y
file, I get it to print a zero return code:

      % sh
      $ bison -y ./getdate.y
      conflicts: 10 shift/reduce
      $ echo $?
      0
      $

(I get this result on a FreeBSD 4.2-RELEASE system using either bison
1.35 or bison 1.875.)

I presume you must be getting a non-zero return code or your make would
not be failing where it is failing. Without further information I don't
know if this is a bug in bison or in HP/UX make.

Fifth, the reason there is a lib/getdate.c is to avoid the problems of
difference between HP/UX and Solaris implementations of that library
function. This is a replacment function from the GNULIB project.

        Good luck,
        -- Mark


_______________________________________________
Info-cvs mailing list
Info-cvs@gnu.org
http://mail.gnu.org/mailman/listinfo/info-cvs