Dmitry Samersoff <dms@wplus.net> writes:
> Problem caused by incorrect const tag usage still exist
> 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)
Ugh. Apparently you're getting bit by c.h's gratuitous#define const
when _STDC_ is not set. This really ought to be handled by a direct
test whether CONST is usable; in fact that whole "#ifdef __STDC__"
section of c.h is pretty bogus. I will work on it.
The problem wouldn't have come up, except that libpq-fe.h doesn't
include config.h or c.h anymore (to avoid polluting application
namespace with huge amounts of Postgres-internal symbols). So the uses
of "const" in libpq-fe.h are seen by the compiler before it sees the
#define, and then when it hits the actual function definitions inside
libpq, it (rightly) complains.
What that means is that no one has yet tried to compile 6.4.* on a
compiler that doesn't recognize "const" (or if anyone did, they didn't
report its failure). Considering that we require compilers to support
ANSI-style function definitions, and "const" predates ANSI, it seems
unlikely that there'd be any hope of building Postgres with such a
compiler anyway. In short: we could probably just lose the "#define const"
entirely, as well as a lot of the other alleged support for pre-ANSI
compilers in c.h.
> or (worst) patch configure to add -std to CFLAGS
What's worst about that? If your compiler is not really ANSI without it,
it seems like a good idea to me. What is your platform exactly?
Does it have a template file? Adding -std to CFLAGS in the template
would be simple enough...
regards, tom lane