Thread: multiple exception definition in pg_type.h -> error compiling postgres support in Qt with gcc v3.2 (SuSE 8.1)

Your name               :       Frank van Vugt
Your email address      :       ftm.van.vugt@foxi.nl

(with thanks to Dimitri@TrollTech for his insight & examples)

System Configuration
---------------------
  Architecture  :
        Intel Pentium III

  Operating System :
        Linux 2.4.19 with glibc 2.2.5 (SuSE v8.1)

  PostgreSQL version :
        PostgreSQL-7.2.3

  Compiler used :
        gcc v3.2


Please enter a FULL description of your problem:
------------------------------------------------

Postgresql itself compiles like a breeze, no problem there.
Config line: "./configure  --with-openssl --with-perl --with-CXX"

Upon compiling TrollTech's Qt-library with postgresql support, the process
fails on numerous lines in pg_type.h with the following message:

> In file included from sql/drivers/psql/qsql_psql.cpp:49:
> /usr/src/postgresql/src/include/catalog/pg_type.h:196: declaration of
> `int*
>    __errno_location()' throws different exceptions
> /usr/src/postgresql/src/include/catalog/pg_type.h:195: than previous
>    declaration `int* __errno_location() throw ()'
> [...]




Please describe a way to repeat the problem.   Please try to provide a
concise reproducible example, if at all possible:
----------------------------------------------------------------------

The problem is caused by lines such as:
        DATA(insert OID = 16 (  bool       PGUID  1   1 t b ... _null_ ));
        DESCR("boolean, 'true'/'false'");

Since DATA and DESCR are defined in postgres.h:
        /* these need to expand into some harmless, repeatable declaration */
        #define DATA(x)   extern int errno
        #define DESCR(x)  extern int errno

These lines are eventually expanded into:
        extern int errno;
        extern int errno;

Obviously, compiling the following source produces the same problem:

        #include <errno.h>
        extern int errno;
        extern int errno;

Postgresql itself seems to never include <errno.h> along with
<catalog/pg_type.h>, otherwise it would suffer from the same problem



If you know how this problem might be fixed, list the solution below:
---------------------------------------------------------------------

We might want to expand ( 'DATA', 'DESCR' ) into something else, one of them
anyway ;-)

ftm.van.vugt@foxi.nl writes:
> Postgresql itself seems to never include <errno.h> along with
> <catalog/pg_type.h>, otherwise it would suffer from the same problem

That's hard to believe; I think it's Qt that's doing something strange
here.  Still, the ANSI C standard does discourage what we are doing:

       ...  It is unspecified whether  errno
       is  a macro or an identifier declared with external linkage.
       If a macro definition is suppressed in order  to  access  an
       actual  object,  or a program defines an identifier with the
       name errno, the behavior is undefined.

Seems like almost anything else would be safer than "errno" :-(

Anyone object to doing

    extern int no_such_variable;

instead?

(Note that just having the macros expand to empty won't do,
because then the compiler would see a string of semicolons,
and some compilers warn about that.)

            regards, tom lane

Tom Lane writes:

> ftm.van.vugt@foxi.nl writes:
> > Postgresql itself seems to never include <errno.h> along with
> > <catalog/pg_type.h>, otherwise it would suffer from the same problem
>
> That's hard to believe; I think it's Qt that's doing something strange
> here.

Yeah, like compiling with thread support. ;-)

> Anyone object to doing
>
>     extern int no_such_variable;
>
> instead?

I wouldn't be surprised if some imaginative AIX linker will croak on that,
but let's try it.

--
Peter Eisentraut   peter_e@gmx.net

Tom Lane writes:
> That's hard to believe; I think it's Qt that's doing something strange
> here.

As a newbie on the list, I'm sorry I have to disagree with you, Tom... ;)

The fact that PostgreSQL dissolves stuff into something like:

#include <errno.h>
extern int errno;
extern int errno;

was more of a suprise to me, but I could be missing something here.


>> Anyone object to doing
>>
>>       extern int no_such_variable;
>>
>> instead?
>
>I wouldn't be surprised if some imaginative AIX linker will croak on that,
>but let's try it.

Well, can't say anything on that particular linker, but obviously this woul=
d=20
be a workable solution.


May I ask why you don't want to go with something like:

#define DESCR(x) typedef int postgresql_foo_bar



As far as Qt goes, both their next minor version as well as the next
major release will contain a workaround for this problem, something
like:

#if defined(errno)
# undef errno
#endif
#define errno qt_psql_errno
#include <catalog/pg_type.h>
#undef errno

But I guess the supposed fix will go into the PostgreSQL sourcetree?


Mind you, I don't want to start a discussion on who 'has to' solve
what where and which way is the best ;-)



Anyway, thanks a lot for the rapid responses!




Frank van Vugt

"ir. F.T.M. van Vugt bc." <ftm.van.vugt@foxi.nl> writes:
> May I ask why you don't want to go with something like:

> #define DESCR(x) typedef int postgresql_foo_bar

Because it doesn't work.

$ cat z.c
typedef int postgresql_foo_bar;
typedef int postgresql_foo_bar;
typedef int postgresql_foo_bar;
$ gcc -c z.c
z.c:2: redefinition of `postgresql_foo_bar'
z.c:1: `postgresql_foo_bar' previously declared here
z.c:3: redefinition of `postgresql_foo_bar'
z.c:2: `postgresql_foo_bar' previously declared here

            regards, tom lane

> > May I ask why you don't want to go with something like:
> > #define DESCR(x) typedef int postgresql_foo_bar
>
> Because it doesn't work.
> $ cat z.c
> typedef int postgresql_foo_bar;
> typedef int postgresql_foo_bar;
> $ gcc -c z.c
> z.c:2: redefinition of `postgresql_foo_bar'
> z.c:1: `postgresql_foo_bar' previously declared here

Ah, you got me there, Tom.

Guess I had to know better than to mess with you C-guys unless I'd better m=
ake=20
sure I'd double-checked ;-))


Anyway, thanx again and guys are doing a great job !!



Frank.