I have 722 installed and tried to build 723.
723 fails to compile. Attached to this message is the output
of the build as captured by script(1).

I already sent a PR to freebsd-ports but the answer was that
this already happened and people got to compile it without
changing anything (that they knew of, I guess).
I am getting this error with FreeBSD-4.6.2p2 through 4.7RC0
and now 4.7-STABLE (updated last night)

Someone mentioned that this error is related to the lack of
awk in the system. I have:
awk: /usr/bin/awk
nawk: /usr/bin/nawk
and just in case I added a link in /usr/local/bin (it's in
the PATH): gawk -> /usr/bin/awk
[fernan@pi] awk --version
GNU Awk 3.0.6
Copyright (C) 1989, 1991-2000 Free Software Foundation.

I am now turning to postgres people for help. I am writing
pgsql-ports as said on the pgsql mailing lists page.

[fernan@pi] uname -a
FreeBSD pi.iib.unsam.edu.ar 4.7-STABLE FreeBSD 4.7-STABLE #1: Fri Oct 18 12:15:57 ART 2002 fernan@pi.iib.unsam.edu.ar:/usr/obj/usr/src/sys/PI i386

[fernan@pi] gcc --version
2.95.4
[fernan@pi] cc --version
2.95.4

Thanks in advance for any tip or suggestion,

Fernan

--
F e r n a n A g u e r o
http://genoma.unsam.edu.ar/~fernan

Search Discussions

  • Tom Lane at Oct 21, 2002 at 2:18 pm

    Fernan Aguero writes:
    723 fails to compile. Attached to this message is the output
    of the build as captured by script(1).
    Er, you forgot the attachment...

    regards, tom lane
  • Tom Lane at Oct 21, 2002 at 5:05 pm

    Fernan Aguero writes:
    cc -O -pipe -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../.=
    ./src/include -I/usr/local/include -c -o tuptoaster.o tuptoaster.c=0D
    tuptoaster.c: In function `toast_delete_datum':=0D
    tuptoaster.c:914: `F_OIDEQ' undeclared (first use in this function)=0D
    tuptoaster.c:914: (Each undeclared identifier is reported only once=0D
    tuptoaster.c:914: for each function it appears in.)=0D
    tuptoaster.c: In function `toast_fetch_datum':=0D
    tuptoaster.c:997: `F_OIDEQ' undeclared (first use in this function)=0D
    gmake[5]: *** [tuptoaster.o] Error 1=0D
    This symptom usually means that the src/backend/utils/Gen_fmgrtab.sh script
    failed to build a valid fmgroids.h file. This part of your trace looks
    pretty suspicious:

    /usr/local/bin/gmake -C utils fmgroids.h
    gmake[4]: Entering directory `/usr/ports/databases/postgresql7/work/postgresql-7.2.3/src/backend/utils'
    CPP='cc -E' AWK='nawk' /bin/sh Gen_fmgrtab.sh ../../../src/include/catalog/pg_proc.h
    cc -E: not found
    gmake[4]: Leaving directory

    I think there's something wrong with your /bin/sh --- it looks to be
    trying to interpret the -E switch as part of the cc filename. Anyone
    seen anything like that before? Setting CPP to 'gcc -E' or 'cc -E' is
    the usual value, so it's not like this is untested ...

    regards, tom lane
  • Fernan Aguero at Oct 22, 2002 at 1:25 pm
    Hi Tom,

    thanks for your reply. Indeed you hit the point rightly. See
    below.

    +----[ Esto dijo Tom Lane (tgl@sss.pgh.pa.us):
    Fernan Aguero <fernan@iib.unsam.edu.ar> writes:
    cc -O -pipe -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../.=
    ./src/include -I/usr/local/include -c -o tuptoaster.o tuptoaster.c=0D
    tuptoaster.c: In function `toast_delete_datum':=0D
    tuptoaster.c:914: `F_OIDEQ' undeclared (first use in this function)=0D
    tuptoaster.c:914: (Each undeclared identifier is reported only once=0D
    tuptoaster.c:914: for each function it appears in.)=0D
    tuptoaster.c: In function `toast_fetch_datum':=0D
    tuptoaster.c:997: `F_OIDEQ' undeclared (first use in this function)=0D
    gmake[5]: *** [tuptoaster.o] Error 1=0D
    This symptom usually means that the src/backend/utils/Gen_fmgrtab.sh script
    failed to build a valid fmgroids.h file. This part of your trace looks
    pretty suspicious:

    /usr/local/bin/gmake -C utils fmgroids.h
    gmake[4]: Entering directory `/usr/ports/databases/postgresql7/work/postgresql-7.2.3/src/backend/utils'
    CPP='cc -E' AWK='nawk' /bin/sh Gen_fmgrtab.sh ../../../src/include/catalog/pg_proc.h
    cc -E: not found
    gmake[4]: Leaving directory
    The problem is here, no doubt. This was also pointed by
    someone at the freebsd-ports@freebsd.org mailing list.
    I think there's something wrong with your /bin/sh --- it looks to be
    trying to interpret the -E switch as part of the cc filename. Anyone
    seen anything like that before? Setting CPP to 'gcc -E' or 'cc -E' is
    the usual value, so it's not like this is untested ...
    I guess that this might be the FreeBSD ports Makefile
    messing things up. In FreeBSD all ports are compiled from a
    Makefile (call it meta-Makefile) that sets some variables,
    drives the inclusion of FBSD specific patches, provides for
    a unified localization of non-system base binaries,
    libraries, etc. I guess that either the Makefile for the
    postgresql7 port (easy) or some of the more general bsd.*.mk
    files (that are included in each ports makefile, more
    difficult to fix, since this can break thousands of ports) is
    conflicting with postgresql's own Makefiles.

    Calling make like this worked, and pgsql compiled OK:
    env -i PATH=$PATH make
    (note that I don't call make within the extracted pgsql
    sources (i.e. on pgsql's Makefile) but on the ports
    meta-Makefile).

    So my guess, again, is that it was a pretty simple fix, and
    that the FreeBSD ports Makefiles (whichever) are the ones
    breaking it.

    Thanks again for your reply,

    Fernan
    regards, tom lane
    +----]

    --
    F e r n a n A g u e r o
    http://genoma.unsam.edu.ar/~fernan
  • Tom Lane at Oct 22, 2002 at 1:34 pm

    Fernan Aguero writes:
    I guess that this might be the FreeBSD ports Makefile
    messing things up. In FreeBSD all ports are compiled from a
    Makefile (call it meta-Makefile) that sets some variables,
    drives the inclusion of FBSD specific patches, provides for
    a unified localization of non-system base binaries,
    libraries, etc. I guess that either the Makefile for the
    postgresql7 port (easy) or some of the more general bsd.*.mk
    files (that are included in each ports makefile, more
    difficult to fix, since this can break thousands of ports) is
    conflicting with postgresql's own Makefiles.
    But how come we've not heard complaints from anyone else using FreeBSD?

    regards, tom lane
  • Larry Rosenman at Oct 22, 2002 at 1:38 pm

    On Tue, 2002-10-22 at 08:34, Tom Lane wrote:
    Fernan Aguero <fernan@iib.unsam.edu.ar> writes:
    I guess that this might be the FreeBSD ports Makefile
    messing things up. In FreeBSD all ports are compiled from a
    Makefile (call it meta-Makefile) that sets some variables,
    drives the inclusion of FBSD specific patches, provides for
    a unified localization of non-system base binaries,
    libraries, etc. I guess that either the Makefile for the
    postgresql7 port (easy) or some of the more general bsd.*.mk
    files (that are included in each ports makefile, more
    difficult to fix, since this can break thousands of ports) is
    conflicting with postgresql's own Makefiles.
    But how come we've not heard complaints from anyone else using FreeBSD?
    I just (yesterday) did a recompile of 7.2.3, and it worked fine from
    CURRENT FreeBSD Ports. FWIW.

    LER


    --
    Larry Rosenman http://www.lerctr.org/~ler
    Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
    US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
  • Fernan Aguero at Oct 22, 2002 at 2:03 pm
    +----[ Esto dijo Tom Lane (tgl@sss.pgh.pa.us):
    Fernan Aguero <fernan@iib.unsam.edu.ar> writes:
    I guess that this might be the FreeBSD ports Makefile
    messing things up. In FreeBSD all ports are compiled from a
    Makefile (call it meta-Makefile) that sets some variables,
    drives the inclusion of FBSD specific patches, provides for
    a unified localization of non-system base binaries,
    libraries, etc. I guess that either the Makefile for the
    postgresql7 port (easy) or some of the more general bsd.*.mk
    files (that are included in each ports makefile, more
    difficult to fix, since this can break thousands of ports) is
    conflicting with postgresql's own Makefiles.
    But how come we've not heard complaints from anyone else using FreeBSD?
    Don't know, but:

    i) you can always compile from sources without using the
    FreeBSD ports system. Perhaps this kind of users don't see
    this problems.

    ii) Not all users carry the exact same FreeBSD ports tree.
    Differences in the main bsd.*.mk files could have been
    introduced after updating the postgresql7 port to 723. But
    this is just a wild guess.

    The problem I reported has been experienced by others.
    See the following thread:
    http://docs.freebsd.org/cgi/getmsg.cgi?fetch=263497+0+current/freebsd-ports
    Based on this problem reports (PRs):
    http://www.freebsd.org/cgi/query-pr.cgi?pr=44327
    http://www.freebsd.org/cgi/query-pr.cgi?pr=44097
    regards, tom lane
    regards,

    Fernan (thanks again)
    +----]

    --
    F e r n a n A g u e r o
    http://genoma.unsam.edu.ar/~fernan
  • Peter Eisentraut at Oct 23, 2002 at 9:44 pm

    Fernan Aguero writes:

    Calling make like this worked, and pgsql compiled OK:
    env -i PATH=$PATH make
    (note that I don't call make within the extracted pgsql
    sources (i.e. on pgsql's Makefile) but on the ports
    meta-Makefile).
    In that case it would be instructive to see what's actually in your
    environment. Try to unset each environment variable and see which one
    makes the problem go away.

    --
    Peter Eisentraut peter_e@gmx.net

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-ports @
categoriespostgresql
postedOct 18, '02 at 6:29p
activeOct 23, '02 at 9:44p
posts8
users4
websitepostgresql.org
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase