Re: [HACKERS] DEC OSF1 Compilation problems

From: "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu>
To: "Pedro J(dot) Lobo" <pjlobo(at)euitt(dot)upm(dot)es>, "Marc G(dot) Fournier" <scrappy(at)hub(dot)org>
Cc: Dmitry Samersoff <dms(at)wplus(dot)net>, pgsql <pgsql-hackers(at)hub(dot)org>, Michael Meskes <Michael(dot)Meskes(at)usa(dot)net>
Subject: Re: [HACKERS] DEC OSF1 Compilation problems
Date: 1999-02-05 03:24:22
Message-ID: 36BA6466.CCDAEF7F@alumni.caltech.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> >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.

The other large parser, for ecpg, should probably ship both .y and .c
files, but does not yet, so perhaps bison needs to be used anyway. We
should fix this in an upcoming release.

To fix the cvs checkout problem, we might consider having a canned
routine which updates these time tags after a cvs checkout and before
the tar file is constructed...

- Tom

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 1999-02-05 03:38:06 Re: [HACKERS] DEC OSF1 Compilation problems
Previous Message Tatsuo Ishii 1999-02-05 01:05:25 Re: [HACKERS] Backend problem with large objects