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


Wed, 3 Feb 1999 21:51:59 +0300 (MSK)
Dmitry Samersoff <dms@wplus.net>
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

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

Wed, 3 Feb 1999 14:12:01 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] DEC OSF1 Compilation problems
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

Wed, 03 Feb 1999 15:06:10 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] DEC OSF1 Compilation problems 
> 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, Pennsylvania 19026

Wed, 3 Feb 1999 15:10:21 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] DEC OSF1 Compilation problems
> > 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

Thu, 04 Feb 1999 02:52:41 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [HACKERS] DEC OSF1 Compilation problems
> > 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


Thu, 4 Feb 1999 12:25:09 +0300 (MSK)
Dmitry Samersoff <dms@wplus.net>
Re: [HACKERS] DEC OSF1 Compilation problems
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


Thu, 4 Feb 1999 11:00:50 +0100 (MET)
"Pedro J. Lobo" <pjlobo@euitt.upm.es>
Re: [HACKERS] DEC OSF1 Compilation problems
> >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

Fri, 05 Feb 1999 03:24:22 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [HACKERS] DEC OSF1 Compilation problems
> > >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

Thu, 4 Feb 1999 22:38:06 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] DEC OSF1 Compilation problems
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!

Fri, 5 Feb 1999 13:32:03 +0100
Michael Meskes <Michael_Meskes@topmail.de>
Re: [HACKERS] DEC OSF1 Compilation problems
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.                     |
=====================================================================
5 Feb 1999 08:28:39 -0500
geek+@cmu.edu
Re: [HACKERS] DEC OSF1 Compilation problems
> > 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

Fri, 05 Feb 1999 13:51:20 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [HACKERS] DEC OSF1 Compilation problems
> 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

Fri, 05 Feb 1999 14:02:20 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [HACKERS] DEC OSF1 Compilation problems
> 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

Fri, 5 Feb 1999 12:24:28 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] DEC OSF1 Compilation problems
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!

Sat, 6 Feb 1999 12:47:32 +0100
Michael Meskes <Michael.Meskes@gmx.net>
Re: [HACKERS] DEC OSF1 Compilation problems