SEO

While building 8.1.1 on Tru64 UNIX 5.1:
gmake[5]: Leaving directory `/opt/build/postgresql-8.1.1/src/port'
cc -O2 -ieee -msym -readonly_strings -pthread --thread-safe
-D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS -I./../include
-I. -I../../../../src/include -I/opt/TWWfsw/gettext014/include
-I/opt/TWWfsw/readline50/include -I/opt/TWWfsw/libopenssl097/include
-I/opt/TWWfsw/zlib11/include -I/opt/TWWfsw/tcl84/include
-I/opt/TWWfsw/tk84/include -DMAJOR_VERSION=4 -DMINOR_VERSION=1
-DPATCHLEVEL=1 -c -o preproc.o preproc.c
cc: Error: /usr/include/arpa/nameser_compat.h, line 154: Invalid
declarator. (declarator)
} HEADER;
--^

The problem is that /usr/include/arpa/nameser_compat.h defines a
struct named HEADER. This conflicts with the use of preproc.y in
src/interfaces/ecpg/preproc/preproc.y.

What should it be renamed to?

--
albert chin (china@thewrittenword.com)

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Albert Chin <pgsql-hackers@mlists.thewrittenword.com> writes:
> The problem is that /usr/include/arpa/nameser_compat.h defines a
> struct named HEADER. This conflicts with the use of preproc.y in
> src/interfaces/ecpg/preproc/preproc.y.

> What should it be renamed to?

Perhaps a more relevant question is why ecpg/preproc is including
that header.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

On Mon, Dec 19, 2005 at 05:59:12PM -0500, Tom Lane wrote:
> Albert Chin <pgsql-hackers@mlists.thewrittenword.com> writes:
> > The problem is that /usr/include/arpa/nameser_compat.h defines a
> > struct named HEADER. This conflicts with the use of preproc.y in
> > src/interfaces/ecpg/preproc/preproc.y.
>
> > What should it be renamed to?
>
> Perhaps a more relevant question is why ecpg/preproc is including
> that header.

#include <netdb.h> with -D_REENTRANT includes it.
preproc.c:
#include "postgres_fe.h"
#include "c.h"
#include "port.h"
#include <netdb.h>

ADD has the same problem.

--
albert chin (china@thewrittenword.com)

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Albert Chin <pgsql-hackers@mlists.thewrittenword.com> writes:
> On Mon, Dec 19, 2005 at 05:59:12PM -0500, Tom Lane wrote:
>> Perhaps a more relevant question is why ecpg/preproc is including
>> that header.

> #include <netdb.h> with -D_REENTRANT includes it.
> preproc.c:
> #include "postgres_fe.h"
> #include "c.h"
> #include "port.h"
> #include <netdb.h>

Well, port.h is certainly doing a fine job of polluting the namespace.
Maybe we should pull out the stuff that depends on netdb.h and pwd.h
into some other header that isn't going to get included so widely.

> ADD has the same problem.

There's no way that we are going to be able to dodge every single symbol
that any random system header on any random platform might define ---
especially when you get into the less-well-standardized headers like
these. We have to think smaller in terms of what headers we include
everywhere.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

On Mon, Dec 19, 2005 at 06:34:38PM -0500, Tom Lane wrote:
> Albert Chin <pgsql-hackers@mlists.thewrittenword.com> writes:
> > On Mon, Dec 19, 2005 at 05:59:12PM -0500, Tom Lane wrote:
> >> Perhaps a more relevant question is why ecpg/preproc is including
> >> that header.
>
> > #include <netdb.h> with -D_REENTRANT includes it.
> > preproc.c:
> > #include "postgres_fe.h"
> > #include "c.h"
> > #include "port.h"
> > #include <netdb.h>
>
> Well, port.h is certainly doing a fine job of polluting the namespace.
> Maybe we should pull out the stuff that depends on netdb.h and pwd.h
> into some other header that isn't going to get included so widely.
>
> > ADD has the same problem.
>
> There's no way that we are going to be able to dodge every single symbol
> that any random system header on any random platform might define ---
> especially when you get into the less-well-standardized headers like
> these. We have to think smaller in terms of what headers we include
> everywhere.

Well, we've built on most versions of Solaris, HP-UX, AIX, Tru64 UNIX,
Redhat Linux, and IRIX and this is the only symbol conflict we ran
into. So, it's not a big problem.

--
albert chin (china@thewrittenword.com)

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org