Thread
-
DEC OSF1 Compilation problems
Dmitry Samersoff <dms@wplus.net> — 1999-02-03T18:51:59Z
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 -
Re: [HACKERS] DEC OSF1 Compilation problems
Bruce Momjian <maillist@candle.pha.pa.us> — 1999-02-03T19:12:01Z
> 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, Pennsylvania 19026
-
Re: [HACKERS] DEC OSF1 Compilation problems
Thomas Lockhart <lockhart@alumni.caltech.edu> — 1999-02-04T02:52:41Z
> > 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 -
Re: [HACKERS] DEC OSF1 Compilation problems
Dmitry Samersoff <dms@wplus.net> — 1999-02-04T09:25:09Z
> > 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 earlier declaration 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 -
Re: [HACKERS] DEC OSF1 Compilation problems
Pedro J. Lobo <pjlobo@euitt.upm.es> — 1999-02-04T10:00:50Z
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
-
Re: [HACKERS] DEC OSF1 Compilation problems
Thomas Lockhart <lockhart@alumni.caltech.edu> — 1999-02-05T03:24:22Z
> >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 -
Re: [HACKERS] DEC OSF1 Compilation problems
Bruce Momjian <maillist@candle.pha.pa.us> — 1999-02-05T03:38:06Z
> > >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, Pennsylvania 19026
-
Re: [HACKERS] DEC OSF1 Compilation problems
Michael Meskes <michael_meskes@topmail.de> — 1999-02-05T12:32:03Z
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!
-
Re: [HACKERS] DEC OSF1 Compilation problems
Brian E Gallew <geek+@cmu.edu> — 1999-02-05T13:28:39Z
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. | =====================================================================
-
Re: [HACKERS] DEC OSF1 Compilation problems
Thomas Lockhart <lockhart@alumni.caltech.edu> — 1999-02-05T13:51:20Z
> > 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 -
Re: [HACKERS] DEC OSF1 Compilation problems
Thomas Lockhart <lockhart@alumni.caltech.edu> — 1999-02-05T14:02:20Z
> 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 -
Re: [HACKERS] DEC OSF1 Compilation problems
Bruce Momjian <maillist@candle.pha.pa.us> — 1999-02-05T17:24:28Z
> 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, Pennsylvania 19026
-
Re: [HACKERS] DEC OSF1 Compilation problems
Michael Meskes <michael.meskes@gmx.net> — 1999-02-06T11:47:32Z
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!