Re: rcs-5.8 test failures on HP-UX 11.31

[Paul Ackersviller]

On Fri, Apr 06, 2012 at 06:18:45PM +0200, Thien-Thi Nguyen wrote:
> () Paul Ackersviller <address@hidden>
> () Mon, 5 Mar 2012 00:31:08 +0000
> 
>    The good and bad news is that I'm not even able to get a
>    successfult compile now.  I expect at least that things should be
>    easier to recify then.
> 
> Would you be willing to test a version from the public Git repository?

Sure, I'll be glad to, but it may take me a week or two to get there.
I didn't see any instructions on the website for accessing the repo a
month or two ago when I looked... good that you added that in at the end.

>    Both different gcc version I have here end with
>    gcc -std=gnu99 -std=gnu99 -DHAVE_CONFIG_H -I. -I../lib  -I'../lib'    -g 
> -MT ci.o -MD -MP -MF .deps/ci.Tpo -c -o ci.o ci.c
>    ci.c: In function 'main':
>    ci.c:678:15: error: 'help' undeclared (first use in this function)
>    ci.c:678:15: note: each undeclared identifier is reported only once for 
> each function it appears in
>    ci.c:682:3: warning: implicit declaration of function 'CHECK_HV' 
> [-Wimplicit-function-declaration]
> 
> That seems to indicate a problem with the preprocessor, which is
> involved in defining each ???help??? (via #include "ci.help"), which in
> turn defines ???CHECK_HV??? (via #include "gnu-h-v.h").  Or perhaps the
> fault lies w/ the program that produces ci.help.
> 
>    However, since I'm not entirely sure how well gcc works on this
>    platform yet, I'm more inclined to use HP's compiler... but it
>    ends similarly with
> 
>            source='ci.c' object='ci.o' libtool=no \
>            DEPDIR=.deps depmode=hp2 /bin/sh ../build-aux/depcomp \
>            cc -DHAVE_CONFIG_H -I. -I../lib  -I'../lib'    -AC99 -c ci.c
>    "ci.c", line 249: warning #2186-D: pointless comparison of unsigned 
> integer with zero
>                if (!removedlock && 0 <= (removedlock = removelock 
> (targetdelta)))
>                                      ^
> 
> Good catch.  The variable ???removedlock??? used to be ???int???, but i
> changed it to ???bool??? without considering that the return value of
> ???removelock??? is int, and may indeed be negative.  The assignment
> loses information.  This is now fixed with:

Not much help from me, we'll have to thank HP for that one.  Their
compilers seem to be an awful lot better than what they supplied 10
years ago and more.  If you like that I can send you all of the compiler
output next time.