Problem while building SRPM PostgreSQL on Red Hat Linux 9

Devrim GUNDUZ <devrim@gunduz.org> writes:

gcc -O2 -g -pipe -march=i686 -Wall -Wmissing-prototypes
-Wmissing-declarations -I../../../src/include -I/usr/kerberos/include -c
-o hba.o hba.c
hba.c:76: parse error before "c"
hba.c:76: parse error before '&' token
make[3]: *** [hba.o] Error 1

I'm betting the system headers define a macro isblank(). I've always
wondered why we don't have more trouble with that.

Try putting "#ifndef isblank ... #endif" around the isblank function
in hba.c.

regards, tom lane

Tom Lane wrote:

Devrim GUNDUZ <devrim@gunduz.org> writes:

gcc -O2 -g -pipe -march=i686 -Wall -Wmissing-prototypes
-Wmissing-declarations -I../../../src/include -I/usr/kerberos/include -c
-o hba.o hba.c
hba.c:76: parse error before "c"
hba.c:76: parse error before '&' token
make[3]: *** [hba.o] Error 1

I'm betting the system headers define a macro isblank(). I've always
wondered why we don't have more trouble with that.

Try putting "#ifndef isblank ... #endif" around the isblank function
in hba.c.

I just ran into the exact same issue with cvs tip on Red Hat 9. The
ifndef does the trick.

Joe

Joe Conway wrote:

Tom Lane wrote:

I'm betting the system headers define a macro isblank(). I've always
wondered why we don't have more trouble with that.

Try putting "#ifndef isblank ... #endif" around the isblank function
in hba.c.

I just ran into the exact same issue with cvs tip on Red Hat 9. The
ifndef does the trick.

The committed fix now gives me this:

i386-redhat-linux-gcc -O2 -g -Wall -Wmissing-prototypes
-Wmissing-declarations -I../../../src/include -I/usr/kerberos/include
-c -o hba.o hba.c -MMD
hba.c:82: conflicting types for `isblank'
/usr/include/ctype.h:128: previous declaration of `isblank'
make[3]: *** [hba.o] Error 1

Any reason not to apply the following?

Joe

Index: src/backend/libpq/hba.c
===================================================================
RCS file: /opt/src/cvs/pgsql-server/src/backend/libpq/hba.c,v
retrieving revision 1.97
diff -c -r1.97 hba.c
*** src/backend/libpq/hba.c     12 Apr 2003 22:28:33 -0000      1.97
--- src/backend/libpq/hba.c     13 Apr 2003 02:26:45 -0000
***************
*** 73,88 ****
    * Others, including Solaris, do not.  So we have our own.  Watch out for
    * macro-ized versions, too.
    */
! #ifdef isblank
! #undef isblank
! #endif
!
   static bool
   isblank(const char c)
   {
         return c == ' ' || c == '\t' || c == '\r';
   }
!

   /*
    *     Grab one token out of fp. Tokens are strings of non-blank
--- 73,85 ----
    * Others, including Solaris, do not.  So we have our own.  Watch out for
    * macro-ized versions, too.
    */
! #ifndef isblank
   static bool
   isblank(const char c)
   {
         return c == ' ' || c == '\t' || c == '\r';
   }
! #endif

/*
* Grab one token out of fp. Tokens are strings of non-blank

Joe Conway <mail@joeconway.com> writes:

hba.c:82: conflicting types for `isblank'
/usr/include/ctype.h:128: previous declaration of `isblank'
make[3]: *** [hba.o] Error 1

[ scratches head ... ] They have both a macro and an extern definition
of isblank? What is the latter exactly?

Any reason not to apply the following?

I was worried about whether the platform's definition of isblank would
be exactly what we need or not. In particular, it has to accept \r and
reject \n or we've got problems --- *big* problems if it accepts \n.
AFAIK this function isn't standardized so there's no strong reason to
assume it will work in a particular way.

Mebbe the best answer is just to rename our function to pg_isblank...

regards, tom lane

Tom Lane wrote:

Joe Conway <mail@joeconway.com> writes:

hba.c:82: conflicting types for `isblank'
/usr/include/ctype.h:128: previous declaration of `isblank'
make[3]: *** [hba.o] Error 1

[ scratches head ... ] They have both a macro and an extern definition
of isblank? What is the latter exactly?

This is from /usr/include/ctype.h on a clean install of Red Hat 9:

/* ISO C99 introduced one new function. */
#ifdef __USE_ISOC99
__BEGIN_NAMESPACE_C99

__exctype (isblank);

__END_NAMESPACE_C99
#endif

Mebbe the best answer is just to rename our function to pg_isblank...

Sounds like the ticket.

Joe

Joe Conway <mail@joeconway.com> writes:

Tom Lane wrote:

Mebbe the best answer is just to rename our function to pg_isblank...

Sounds like the ticket.

Done and done.

regards, tom lane