Re: [Cvs-dev] Re: [Cvs-test-results] Build CVS (TRUNK) failed.

[Mark D. Baushke]

Jim Hyslop <address@hidden> writes:

> Mark D. Baushke wrote:
> > Hi Folks,
> > 
> > I suspect that the windows-NT build is breaking because it is not
> > compiling and linking the files base.c, gpg.c, sign.c and verify.c.
> > 
> > I do not have a windows-NT system to use to do the build, but I took a
> > guess at hoe the cvsnt.* files may be regenerated and include the diffs
> > here for your use.
> >
> > Will someone who has the right tools try this to see if it helps?
> 
> It's a start :=)

Good. Perhaps if you commit what works, we can see what else still
fails?

> I've been working on this, and once those have been resolved, there's
> still a problem where client.c tries to call strtoumax(). See the thread
> in bug-cvs: http://lists.gnu.org/archive/html/bug-cvs/2006-06/msg00026.html

I guess we need to know if there is a uintmax_t type and/or a
strtoimax() function in your environment or not before anyone else can
help.

> This also requires modifying windows-NT/config.h to define
> HAVE_DECL_STRTOLL, and I'm having a difficult time trying to understand
> the interactions between ./configure.in, ./config.h,
> windows-NT/config.h.in.in, etc.

Ahhh... maybe I can help. windows-NT/config.h.in.in is used to generate
windows-NT/config.h.in by running the makeconfig.pl script to merge the
config.h.in.in and config.h.in.footer file into the config.h.in file and
that is copied into the top-level config.h when building on a windows
box. This is part of the stamp-chi target in the windows-NT/Makefile 

... One other thing, the top-level config.h.in file is used to see if
there are any missing macros out of config.h.in.in that should be added.

So, fix config.h.in.in to add the line defines as you wish them. You
should then either regenerate windows-NT/config.h.in and
windows-NT/config.h or just apply the same patch to those other two
files (whichever you find easier).

I'll add an attachment that might work for you below.

Larry Jones <address@hidden> writes:

> Mark D. Baushke writes:
> > 
> > It would also be a great idea if the information about the breakage for
> > the SGI builds could be forwarded to hte cvs-test-results list.
> 
> Well, it appears that it is compiling now, but only by accident. 
> The problem, which Derek and I discussed a while ago but never resolved,
> is that SGI provides a <stdint.h> that only works in C99 mode, but
> configure doesn't detect that because the SGI compiler doesn't consider
> a #error directive as fatal, it just issues a warning and continues,
> leading to lots of compile warnings like:

I consider that to be a nasty bug in the SGI toolchain. :-(

> 
> source='/u/scjones/cvs-nightly/src/add.c' object='add.o' libtool=no \
> DEPDIR=.deps depmode=sgi /bin/sh /u/scjones/cvs-nightly/build-aux/depcomp \
> cc -mips3 -DHAVE_CONFIG_H -I. -I/u/scjones/cvs-nightly/src -I..  
> -I/u/scjones/cvs-nightly/lib -I../lib -I/u/scjones/cvs-nightly/diff 
> -I/u/scjones/cvs-nightly/zlib -Ino/include  -g -c 
> /u/scjones/cvs-nightly/src/add.c
> cc-1035 cc: WARNING File = /usr/include/stdint.h, Line = 5
>   #error directive:  This header file is to be used only for c99 mode
>           compilations
> 
>   #error This header file is to be used only for c99 mode compilations
>    ^
> 
> Since <inttypes.h> has been around a lot longer than <stdint.h> and is
> supposed to define all the same stuff (plus more), I think the right
> thing to do is include just <inttypes.h> if it exists, and only include
> <stdint.h> if it doesn't.  The only problem is that many of the files
> that include <stdint.h> are in the lib directory and come from gnulib
> rather than being our source files.

The GNULIB files also will be including "config.h" which means that we
can hack around this if we are unable to get support from GNULIB for any
other possibility. I just don't like adding per-OS hacks to the
templated config.h file if there is any way around it.

That said, my understanding is that C99 mandates both <stdint.h> and
<inttypes.h>. The latter was around on some systems prior to the C99
standard.

The only reason that GNULIB includes the <stdint.h> file is because it
provides a stdint_.h 'replacement' .h file that may be used if one is
not otherwise available. The problem would seem to be that on SGI, we
need to force inclusion of <inttypes.h> in default C89 behavior or
somehow direct the SGI compiler to force C99 mode operations.

        -- Mark

cvs-windows.patch
Description: Possible hack to windows-NT/config.h* for HAVE_DECL_STRTOLL

pgpiO3d7J6buP.pgp
Description: PGP signature