Обсуждение: 6.4 BETA2 fails to compile on Digital Unix 4.0d

Hi, all.

I am testing 6.4 on a DU 4.0d system using DEC's (well, Compaq's) C
compiler, gmake 3.75, bison 1.25 and flex 2.5.4, and I've found two
problems.

1 - The old "configure --with-CC=cc" problem is still there: configure
fails if you specify --with-CC=cc when it is going to test whether the C
compiler needs the "-traditional" flag. I think I remember it was due to a
bug in autoconf itself, so there isn't much to be done, except patch the
configure script by hand before making the release. I can supply a patch,
if needed.

2 - I get the following error when compiling:

cc -I../../../include -I../../../backend   -I/usr/local/include -DNOFIXADE -O4 -Olimit 2000  -I../..    -c istrat.c -o
istrat.o
cc: Error: istrat.c, line 495: In this statement, "F_OIDEQ" is not declared.
             F_OIDEQ,
 
-----------------------------------------------------------^
cc: Error: istrat.c, line 561: In this statement, "F_OIDEQ" is not declared.
             F_OIDEQ,
 
-----------------------------------------------------------^
cc: Error: istrat.c, line 604: In this statement, "F_OIDEQ" is not declared.
             F_OIDEQ,
 
-----------------------------------------------------------^
cc: Error: istrat.c, line 642: In this statement, "F_OIDEQ" is not declared.
     F_OIDEQ,
 
---------------------------------------------------^
gmake[3]: *** [istrat.o] Error 1
gmake[3]: Leaving directory
`/usr/local/pgsql.beta/src/pgsql/src/backend/access/
index'
gmake[2]: *** [submake] Error 2
gmake[2]: Leaving directory
`/usr/local/pgsql.beta/src/pgsql/src/backend/access'
gmake[1]: *** [access.dir] Error 2
gmake[1]: Leaving directory `/usr/local/pgsql.beta/src/pgsql/src/backend'
gmake: *** [all] Error 2

It bombs compiling backend/access/index/istrat.c. I have searched all the
occurences of "F_OIDEQ" in all files (that is all files, not just .c or
.h), and found it in the following ones:

./backend/access/index/istrat.c
./backend/catalog/heap.c
./backend/catalog/index.c
./backend/catalog/indexing.c
./backend/catalog/pg_operator.c
./backend/commands/remove.c
./backend/commands/trigger.c
./backend/commands/vacuum.c
./backend/executor/execUtils.c
./backend/optimizer/path/indxpath.c
./backend/optimizer/util/plancat.c
./backend/parser/parse_func.c
./backend/rewrite/rewriteRemove.c
./backend/utils/adt/selfuncs.c
./backend/utils/cache/catcache.c
./backend/utils/cache/relcache.c

As you can see, F_OIDEQ isn't defined in any header file nor in any other
kind of config file. I've also searched in /usr/include/... and
/usr/local/include..., just in case.

Any hints?

P.S.: I've also noticed that there is a "F_OID8EQ" that's found only in
backend/catalog/indexing.c and backend/utils/cache/catcache.c.

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

> I am testing 6.4 on a DU 4.0d system using DEC's (well, Compaq's) C
> compiler, gmake 3.75, bison 1.25 and flex 2.5.4, and I've found two
> problems.
> Any hints?

I'm guessing that you have a problem with having your "cpp" preprocessor
pick up input from a pipe (stdin). Just yesterday Tom Lane fixed that by
no longer requiring cpp or equivalent to do that. Can you look at your
configure results and verify that the conclusions it reaches about CPP
and CPPSTDIN are correct?

The two scripts which use it are src/backend/utils/Gen_fmgrtab.sh and
src/backend/catalog/genbki.sh. Go to src/backend/utils and type "make"
and see if files are made as you would expect. If there is a problem,
then perhaps Tom can send you new versions, or you can hand-modify them
yourself, or you can wait for a new beta. In Gen_fmgrtab.sh.in the new
code looks like:

42a43
> CPPTMPFILE=fmgrtmp.c
65,66c66,68
< $4 == "11"    { print; next; }' | \
< @CPP@ @CPPSTDIN@ $BKIOPTS | \
---
> $4 == "11"    { print; next; }' > $CPPTMPFILE
>
> @CPP@ $BKIOPTS $CPPTMPFILE | \
69a72,73
> rm -f $CPPTMPFILE

to have cpp read from file fmgrtmp.c rather than from stdin.
                        - Tom

"Pedro J. Lobo" <pjlobo@euitt.upm.es> writes:
> 1 - The old "configure --with-CC=cc" problem is still there: configure
> fails if you specify --with-CC=cc when it is going to test whether the C
> compiler needs the "-traditional" flag. I think I remember it was due to a
> bug in autoconf itself, so there isn't much to be done, except patch the
> configure script by hand before making the release. I can supply a patch,
> if needed.

Can you send me the details on this one?  I'm not real eager for us to
try to apply a hand patch to configure (it would get lost, because we
change configure.in and rerun autoconf every few days, seems like).
But maybe there is another way.  In any case, I can try to make sure
that the next release of Autoconf fixes the underlying problem.

> 2 - I get the following error when compiling:

> cc -I../../../include -I../../../backend   -I/usr/local/include -DNOFIXADE -O4 -Olimit 2000  -I../..    -c istrat.c
-oistrat.o
 
> cc: Error: istrat.c, line 495: In this statement, "F_OIDEQ" is not declared.

This is a symptom of incorrect configure guess about how to do
cpp-from-stdin ... the file that should contain the definition of
F_OIDEQ is winding up empty :-(

It should be fixed in the current CVS sources, or BETA4 whenever that's
out.
        regards, tom lane

On Thu, 29 Oct 1998, Thomas G. Lockhart wrote:

>> I am testing 6.4 on a DU 4.0d system using DEC's (well, Compaq's) C
>> compiler, gmake 3.75, bison 1.25 and flex 2.5.4, and I've found two
>> problems.
>> Any hints?
>
>I'm guessing that you have a problem with having your "cpp" preprocessor
>pick up input from a pipe (stdin). Just yesterday Tom Lane fixed that by
>no longer requiring cpp or equivalent to do that. Can you look at your
>configure results and verify that the conclusions it reaches about CPP
>and CPPSTDIN are correct?

It seems that you won the prize :-) I have patched Gen_fmgrtab.sh.in and
genbki.sh.in and executed configure again, and now it is compiling fine.

One "minor" problem is that I am getting many warnings complaining that
MAP_FILE is being redefined. Indeed, it is defined in
/usr/include/sys/mman.h (a system header file) for being used with mmap
and friends, and is redefined in include/libpq/hba.h. Since hba.h is
parsed after mmap.h and the preprocessor uses the last value seen
everything is allright, but I think that MAP_FILE should be renamed to
something like PG_MAP_FILE. Maybe it can wait for 6.4.1 or 6.5, but it
should be done.

I'll post a complete report if/when the build ends and (hopefully) the
regression tests are completed.

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

On Thu, 29 Oct 1998, Tom Lane wrote:

>"Pedro J. Lobo" <pjlobo@euitt.upm.es> writes:
>> 1 - The old "configure --with-CC=cc" problem is still there: configure
>> fails if you specify --with-CC=cc when it is going to test whether the C
>> compiler needs the "-traditional" flag. I think I remember it was due to a
>> bug in autoconf itself, so there isn't much to be done, except patch the
>> configure script by hand before making the release. I can supply a patch,
>> if needed.
>
>Can you send me the details on this one?  I'm not real eager for us to
>try to apply a hand patch to configure (it would get lost, because we
>change configure.in and rerun autoconf every few days, seems like).

Yes, it would be a real pain. I was considering it only as the last
option.

>But maybe there is another way.  In any case, I can try to make sure
>that the next release of Autoconf fixes the underlying problem.

Ok, here's what happens: the line "AC_PROG_GCC_TRADITIONAL" in
configure.in expands to the following in configure:

if test $ac_cv_prog_gcc = yes; then   echo $ac_n "checking whether ${CC-cc} needs -traditional""... $ac_c" 1>&6
echo "configure:3961: checking whether ${CC-cc} needs -traditional" >&5
if eval "test \"`echo '$''{'ac_cv_prog_gcc_traditional'+set}'`\" = set"; then
[ more follows ]

The problem is that $ac_cv_prog_gcc is empty if you specify
"--with-CC=", so the first line expands to "if test  = yes; then", which
is clearly incorrect.

My workaround is to substitute the first line with "if test
x$ac_cv_prog_gcc = xyes; then" in configure itself. Dirty, but it works.

>> 2 - I get the following error when compiling:
>
>> cc -I../../../include -I../../../backend   -I/usr/local/include -DNOFIXADE -O4 -Olimit 2000  -I../..    -c istrat.c
-oistrat.o
 
>> cc: Error: istrat.c, line 495: In this statement, "F_OIDEQ" is not declared.
>
>This is a symptom of incorrect configure guess about how to do
>cpp-from-stdin ... the file that should contain the definition of
>F_OIDEQ is winding up empty :-(

Yes, that was the problem. I fixed Gen_fmgrtab.sh.in and genbki.in as
Thomas suggested, and the thing compled (mostly) fine.

>It should be fixed in the current CVS sources, or BETA4 whenever that's
>out.

I don't know if I will be able to test BETA4, because I'm leaving for a
short vacation (lucky me :-) on Saturday and won't be back until Thursday.
However, it should work as expected.

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

On Thu, 29 Oct 1998, Tom Lane wrote:

> "Pedro J. Lobo" <pjlobo@euitt.upm.es> writes:
> > 1 - The old "configure --with-CC=cc" problem is still there: configure
> > fails if you specify --with-CC=cc when it is going to test whether the C
> > compiler needs the "-traditional" flag. I think I remember it was due to a
> > bug in autoconf itself, so there isn't much to be done, except patch the
> > configure script by hand before making the release. I can supply a patch,
> > if needed.
> 
> Can you send me the details on this one?  I'm not real eager for us to
> try to apply a hand patch to configure (it would get lost, because we
> change configure.in and rerun autoconf every few days, seems like).
> But maybe there is another way.  In any case, I can try to make sure
> that the next release of Autoconf fixes the underlying problem.
If its a bug in autoconf itself, we can patch the autoconf .m4
files directly on Hub.Org, and just make sure we autoconf with that...I
have no problemsm with that...

Marc G. Fournier                                
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 

>     If its a bug in autoconf itself, we can patch the autoconf .m4
> files directly on Hub.Org, and just make sure we autoconf with that...I
> have no problemsm with that...

*** acspecific.m4.orig  Thu Oct 29 12:43:02 1998
--- acspecific.m4       Thu Oct 29 12:49:39 1998
***************
*** 81,87 **** AC_PROG_CC_WORKS AC_PROG_CC_GNU

! if test $ac_cv_prog_gcc = yes; then   GCC=yes dnl Check whether -g works, even if CFLAGS is set, in case the package
dnlplays around with CFLAGS (such as to build both debugging and
 
--- 81,87 ---- AC_PROG_CC_WORKS AC_PROG_CC_GNU

! if test "$ac_cv_prog_gcc" = yes; then   GCC=yes dnl Check whether -g works, even if CFLAGS is set, in case the
packagednl plays around with CFLAGS (such as to build both debugging and
 
***************
*** 215,221 **** AC_DEFUN(AC_PROG_GCC_TRADITIONAL, [AC_REQUIRE([AC_PROG_CC])dnl AC_REQUIRE([AC_PROG_CPP])dnl
! if test $ac_cv_prog_gcc = yes; then     AC_CACHE_CHECK(whether ${CC-cc} needs -traditional,
ac_cv_prog_gcc_traditional,[  ac_pattern="Autoconf.*'x'"
 
--- 215,221 ---- AC_DEFUN(AC_PROG_GCC_TRADITIONAL, [AC_REQUIRE([AC_PROG_CC])dnl AC_REQUIRE([AC_PROG_CPP])dnl
! if test "$ac_cv_prog_gcc" = yes; then     AC_CACHE_CHECK(whether ${CC-cc} needs -traditional,
ac_cv_prog_gcc_traditional,[  ac_pattern="Autoconf.*'x'"
 

Should work... if the other message is correct about the source of the
problem. There really needs to be a sanity check for --with-cc or whatever
it is.

Taral

"Pedro J. Lobo" <pjlobo@euitt.upm.es> writes:
> Ok, here's what happens: the line "AC_PROG_GCC_TRADITIONAL" in
> configure.in expands to the following in configure:

> if test $ac_cv_prog_gcc = yes; then

> The problem is that $ac_cv_prog_gcc is empty if you specify
> "--with-CC=", so the first line expands to "if test  = yes; then", which
> is clearly incorrect.

Ah.  OK, Autoconf is maybe not being too robust here, but it's our bug.
AC_PROG_GCC_TRADITIONAL assumes you've run AC_PROG_CC, and we don't do
that if --with-CC is given.

I will rearrange the configure script so that that's true.  As far as I
can see, there's no reason to run AC_PROG_GCC_TRADITIONAL at all if the
user specifies --with-CC ... if the user wants to override the script's
idea of what C compiler to use, then it's also the user's responsibility
to supply any special CFLAGS that might be needed.  So we can just move
the macro into the "else" case where AC_PROG_CC is run.

The -traditional switch shouldn't be needed anyway in any reasonably
modern gcc installation, so we could probably get away with just
removing that test entirely.  But I'll leave it in.

> I don't know if I will be able to test BETA4, because I'm leaving for a
> short vacation (lucky me :-) on Saturday and won't be back until Thursday.

Have a good trip!
        regards, tom lane

"Taral" <taral@mail.utexas.edu> writes:
> *** acspecific.m4.orig  Thu Oct 29 12:43:02 1998
> --- acspecific.m4       Thu Oct 29 12:49:39 1998

I have just committed a configure.in fix that eliminates the need for
this change.  It turns out that the shell syntax failure was just the
tip of the iceberg: the real problem is that AC_PROG_CC *must* be run
even if there is a user-supplied CC setting.

> There really needs to be a sanity check for --with-cc or whatever it is.

There is: AC_PROG_CC makes sure that the supplied CC setting works,
and incidentally discovers a few other things like whether it is gcc.
Our problem was we were bypassing that macro if --with-CC was given.
        regards, tom lane

If its a bug in autoconf itself, we can patch the autoconf .m4  files directly on Hub.Org, and just make sure we
autoconfwith that...I  have no problemsm with that...
 

Better to create an aclocal or whatever and distribute that so that
anyone running autoconf gets the changes.  Otherwise, it will be
impossible to maintain the configure system.

Cheers,
Brook