[sci.bio.technology] How to compile NYU's gbupdate under AT&T Unix?

jim@crom2.uucp (James P. H. Fuller) (04/17/91)

     Has anyone gotten NYU's gbupdate program (for automatically adding the
nightly updates to GenBank) to compile under AT&T Unix?  I have the Unix
version (v.2.3) obtained from goober.phri.nyu.edu.

     If I run make on the unmodified Makefile, I get

> 	cc -g -c gbupdate.c
> ./gbupdate.h: 60: extra tokens (ignored) after directive
> gbupdate.c: 580: extra tokens (ignored) after directive
> "/usr/include/sys/file.h", line 27: syntax error
> "/usr/include/sys/file.h", line 27: cannot recover from earlier errors:
>  goodbye!
> *** Error code 1
>
> Stop.

Part of this is fixable: line 60 in gbupdate.h is

   #endif GBUPDATE_H

and line 580 of gbupdate.c is

   #endif DONT_CHECK_SPACE

If you substitute an unadorned #endif for both of these, the complaints
about extra tokens go away.  However, it still dies on sys/file.h.  I have
a hard time believing there's really a syntax error in file.h since this
is one of the header files distributed with Unix.  (I'm not saying AT&T is
infallible, but one would think that major bugs in file.h would have been
discovered before now.)  What's going on here??

P.S.  I'm running Interactive v.2.2 (System V r.3.2) which uses the standard
AT&T cc, function library and header files.  Here's the relevant portion of
/usr/include/sys/file.h:


18 /*
19 * One file structure is allocated for each open/creat/pipe call.
20 * Main use is to hold the read/write pointer associated with
21 * each open file.
22 */
23
24 typedef struct file
25 {
26     	char	f_flag;
27	cnt_t	f_count;		/* reference count */
28	union {
29		struct inode *f_uinode;	/* pointer to inode structure */
30		struct file  *f_unext;	/* pointer to next entry in freelist */
31	} f_up;
32	union {
33		off_t	f_off;
34		struct	file *f_slnk;	/* XENIX semaphore queue */
35	} f_un;
36 } file_t;

     
     I'd very much appreciate hearing from anyone who has a port of gbupdate
to any AT&T-derived system or who has a bright idea about what the problem
may be.
                                                  Thanks very much,
                                                  James P. H. Fuller
                                                  jim%crom2@nstar.rn.com