Thread

  1. Re: [HACKERS] 6.4 BETA2 fails to compile on Digital Unix 4.0d

    Tom Lane <tgl@sss.pgh.pa.us> — 1998-10-29T15:58:49Z

    "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 -o istrat.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
    
    
  2. Re: [HACKERS] 6.4 BETA2 fails to compile on Digital Unix 4.0d

    Pedro J. Lobo <pjlobo@euitt.upm.es> — 1998-10-29T17:24:00Z

    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 -o istrat.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
    
    
    
  3. Re: [HACKERS] 6.4 BETA2 fails to compile on Digital Unix 4.0d

    Marc G. Fournier <scrappy@hub.org> — 1998-10-29T17:31:56Z

    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 
    
    
    
  4. RE: [HACKERS] 6.4 BETA2 fails to compile on Digital Unix 4.0d

    Taral <taral@mail.utexas.edu> — 1998-10-29T17:51:24Z

    > 	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
      dnl plays 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 package
      dnl 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
    
    
    
  5. Re: [HACKERS] 6.4 BETA2 fails to compile on Digital Unix 4.0d

    Brook Milligan <brook@trillium.nmsu.edu> — 1998-10-30T00:25:07Z

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