| From: | geek+(at)cmu(dot)edu |
|---|---|
| To: | pgsql <pgsql-hackers(at)hub(dot)org> |
| Subject: | Re: [HACKERS] DEC OSF1 Compilation problems |
| Date: | 1999-02-05 13:28:39 |
| Message-ID: | emacs-smtp-4042-14010-61959-112469@export.andrew.cmu.edu |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Then <lockhart(at)alumni(dot)caltech(dot)edu> spoke up and said:
>
> > >2. gram.y did not compile by yacc (on FreeBSD too)
> > ># woland(dms)~/postgresql-6.4.2/src/backend/parser>yacc -d gram.y
> > ># yacc: f - maximum table size exceeded
> > >fixed by using bison
> > I had always used bison. I will add this to the DU FAQ.
>
> This should not be required in principle, but it is easy with cvs to
> accidentally get the time tags on gram.y and gram.c out of sync, so that
> a "cvs checkout" causes Make to think gram.c needs to be rebuilt. I
> think that v6.4.2 ended up with the times out of sync, as have other
> releases in the past.
If someone with access to CVSROOT on the CVS server would be so kind,
it's easy to set up a rule in commitinfo to automatically create
gram.c from gram.y, thus forcing a new, properly timestamped version
of gram.c to be in the archive.
--
=====================================================================
| JAVA must have been developed in the wilds of West Virginia. |
| After all, why else would it support only single inheritance?? |
=====================================================================
| Finger geek(at)andrew(dot)cmu(dot)edu for my public key. |
=====================================================================
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas G. Lockhart | 1999-02-05 13:51:20 | Re: [HACKERS] DEC OSF1 Compilation problems |
| Previous Message | Michael Meskes | 1999-02-05 12:32:03 | Re: [HACKERS] DEC OSF1 Compilation problems |