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

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, Pennsylvania 19026

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

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, Pennsylvania 19026

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, Pennsylvania 19026

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!

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!

I did that already. They are named preproc.c resp. preproc.h now.

Great! I'm working with an aging development tree, so didn't see the
change...

- Tom

On Mon, Feb 08, 1999 at 03:44:44PM +0000, Thomas G. Lockhart wrote:

I did that already. They are named preproc.c resp. preproc.h now.

Great! I'm working with an aging development tree, so didn't see the
change...

It hasn't been comitted so you couldn't see it even with an up-to-date copy.

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!