Thread: DEC OSF1 Compilation problems
Some compilation problem found while compiling PostgreSQL-6.4.2 on OSF1 V4.0 878 alpha 1. configure (problem because . not in $PATH)743c743< . ./conftest.sh---> . conftest.sh 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 3. src/interfaces/libpq and all dependent sources (like perl5 interface) didn't compile because native cc don't support tag const fixed by #define const in apropriate places 4. (old bug) Inastalation fail if prefix directory (e.g /usr/local/pgsql) doesn't exists -- Dmitry Samersoff DM\S, dms@wplus.net, AIM: Samersoff http://devnull.wplus.net
> Some compilation problem found while compiling > PostgreSQL-6.4.2 on OSF1 V4.0 878 alpha > > 1. configure (problem because . not in $PATH) > 743c743 > < . ./conftest.sh > --- > > . conftest.sh Fixed in current tree. > > 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 Need bison, though gram.c is newer than gram.y, or it should be in the tar file. > > 3. src/interfaces/libpq and all dependent sources (like perl5 interface) > didn't compile because native cc don't support tag const > fixed by > #define const > in apropriate places Hard to figure they don't support const. > > 4. (old bug) Inastalation fail if prefix directory > (e.g /usr/local/pgsql) doesn't exists I am fixing this now. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian <maillist@candle.pha.pa.us> writes:
>> 4. (old bug) Inastalation fail if prefix directory
>> (e.g /usr/local/pgsql) doesn't exists
> I am fixing this now.
Are you sure it's a good idea to do anything other than fail?
In a typical setup, the parent directory of the install target
(ie, /usr/local) is going to be owned by root. If you are able
to create the install target it means the installation is being
done as root. We do *not* want to encourage people to install
as root, methinks.
I think the correct response is to leave the software alone and
fix the documentation to remind people to create the top-level
directory (as root) before running "make install" (as postgres).
/usr/local/pgsql should be owned by postgres, so the install can
proceed from that point without root privileges.
regards, tom lane
> Bruce Momjian <maillist@candle.pha.pa.us> writes: > >> 4. (old bug) Inastalation fail if prefix directory > >> (e.g /usr/local/pgsql) doesn't exists > > > I am fixing this now. > > Are you sure it's a good idea to do anything other than fail? > > In a typical setup, the parent directory of the install target > (ie, /usr/local) is going to be owned by root. If you are able > to create the install target it means the installation is being > done as root. We do *not* want to encourage people to install > as root, methinks. > > I think the correct response is to leave the software alone and > fix the documentation to remind people to create the top-level > directory (as root) before running "make install" (as postgres). > /usr/local/pgsql should be owned by postgres, so the install can > proceed from that point without root privileges. OK, I started to agree with you after I tried adding it. I will leave it alone. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> > 2. gram.y did not compile by yacc (on FreeBSD too)
> > fixed by using bison
> Need bison, though gram.c is newer than gram.y, or it should be in the
> tar file.
We've gotten a few reports on this, so I'll guess that we have a too-new
gram.y in the distribution (again) :(
The workaround, besides installing bison, is to type
$ touch backend/parser/gram.c
before typing
$ make $ make install
- Tom
> > 3. src/interfaces/libpq and all dependent sources (like perl5 interface) > > didn't compile because native cc don't support tag const > > fixed by > > #define const > > in apropriate places > > Hard to figure they don't support const. Sorry, it's my mistake, better say - problem around supporting const (on Solaris it looks to be the same, but I'm not sure) This is compiler message ---------------------------------------- cc: Error: fe-connect.c, line 173: In this declaration, parameter 1 has a different type than specified in an earlierdeclaration of this function. PQconnectdb(const char *conninfo) ^ cc: Error: fe-connect.c, line 173: In this declaration, the type of "PQconnectdb" is not compatible with the type of a previous declaration of "PQconnectdb" at line number 153 in file libpq-fe.h. ---------------------------------------------------------------------------- Real declaration (fe-connect.c:173) : PGconn * PQconnectdb(const char *conninfo) (libpq-fe.h:153):extern PGconn *PQconnectdb(const char *conninfo); -- Dmitry Samersoff DM\S, dms@wplus.net, AIM: Samersoff http://devnull.wplus.net
On Wed, 3 Feb 1999, Dmitry Samersoff wrote: >Some compilation problem found while compiling >PostgreSQL-6.4.2 on OSF1 V4.0 878 alpha > >1. configure (problem because . not in $PATH) > 743c743 > < . ./conftest.sh > --- > > . conftest.sh I don't know why this happens in 6.4.2, because it didn't in 6.4.1. You have applied the right fix/workaround. > >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. >3. src/interfaces/libpq and all dependent sources (like perl5 interface) >didn't compile because native cc don't support tag const >fixed by > #define const > in apropriate places The right fix is to add "-std" to the CFLAGS line in template/alpha. This is already fixed in 6.5 beta. -- ------------------------------------------------------------------- Pedro José Lobo Perea Tel: +34 91 336 78 19 Centro de Cálculo Fax: +34 91 331 92 29 EUIT Telecomunicación - UPM e-mail: pjlobo@euitt.upm.es
> >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
> > >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... Is there some way to do this fixup in the makefile? -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Thu, Feb 04, 1999 at 10:38:06PM -0500, Bruce Momjian wrote: > > 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. I have included both files in my latest patch. > Is there some way to do this fixup in the makefile? Tell me what to do. Michael -- Michael Meskes | Go SF 49ers! Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire! Tel.: (+49) 2431/72651 | Use Debian GNU/Linux! Email: Michael.Meskes@gmx.net | Use PostgreSQL!
Then <lockhart@alumni.caltech.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@andrew.cmu.edu for my public key. | =====================================================================
> > 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...
> Is there some way to do this fixup in the makefile?
Well, maybe, but that would defeat the purpose of the makefile. Unless
we had a "make release-tarball" at the top level? That could have some
embedded file touches in it...
I like geek+'s suggestion to build with a commit rule in cvs, if it can
be done without having the whole tree set up and made. otoh this would
increase the maintenance effort a bit, since we would have to maintain
the rules.
- Tom
> I have included both files in my latest patch.
Great. Bruce and scrappy, whoever applies this will need to add this as
a new file in cvs. At the moment the file is named y.tab.c (and
y.tab.h), but we might want to consider renaming it as is done in the
main parser to keep the names unique within the installation (for
example, y.tab.c is probably also a temporary file in
src/backend/parser/).
> > Is there some way to do this fixup in the makefile?
> Tell me what to do.
Doing this in the local makefile is probably dangerous or at least
annoying. Let's not be hasty in adopting a fix for this out of sync
problem. We should remember that any heuristic like this might also mask
the fact that we have forgotten to update the gram.c before a release.
imho the best way to ensure sync is for Bruce, myself, and anyone else
who commits parser stuff to commit gram.y and scan.l first, then gram.c
and scan.c afterwards. The cvs time tags will be consistant then.
Also, our pre-release checking apparently does not alway catch this
problem; perhaps we should figure out a way to build with a dummy
yacc/bison for this final verification, so things barf if it is actually
invoked.
- Tom
> On Thu, Feb 04, 1999 at 10:38:06PM -0500, Bruce Momjian wrote: > > > 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. > > I have included both files in my latest patch. > > > Is there some way to do this fixup in the makefile? > > Tell me what to do. I don't know how to do it reliably. If someone edits gram.y, we want gram.c to be regenerated, but we don't if gram.y is the one from the tar file. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Fri, Feb 05, 1999 at 02:02:20PM +0000, Thomas G. Lockhart wrote: > Great. Bruce and scrappy, whoever applies this will need to add this as > a new file in cvs. At the moment the file is named y.tab.c (and > y.tab.h), but we might want to consider renaming it as is done in the > main parser to keep the names unique within the installation (for > example, y.tab.c is probably also a temporary file in > src/backend/parser/). I did that already. They are named preproc.c resp. preproc.h now. Michael -- Michael Meskes | Go SF 49ers! Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire! Tel.: (+49) 2431/72651 | Use Debian GNU/Linux! Email: Michael.Meskes@gmx.net | Use PostgreSQL!