#149 build conflict with numarray and GCC4

v2.0.1
open
nobody
build (28)
5
2006-09-25
2006-09-25
Daniel Drake
No

Hi,

Here's an annoying bug that can't really be pinpointed
on anyone in particular. Any ideas?

creating build/temp.linux-x86_64-2.4/src/interface_util
x86_64-pc-linux-gnu-gcc -pthread -fno-strict-aliasing
-DNDEBUG -O2 -pipe -fPIC -DGLX_PLATFORM -DNUMERIC
-I/usr/include/python2.4 -I/usr/include
-I/usr/local/include -I/usr/X11/include
-I/usr/X11R6/include -I/usr/include/python2.4/numarray
-I/usr/include/python2.4/Numeric -I/usr/include
-I/usr/local/include -I/usr/X11/include
-I/usr/X11R6/include -I/usr/include/python2.4/numarray
-I/usr/include/python2.4/Numeric -c
src/interface_util/interface_util.c -o
build/temp.linux-x86_64-2.4/src/interface_util/interface_util.o
In file included from
/usr/include/python2.4/numarray/arrayobject.h:19,
from src/interface_util/../config.h:162,
from
src/interface_util/interface_util.c:1:
/usr/include/python2.4/numarray/arraybase.h:27: error:
two or more data types in declaration specifiers
/usr/include/python2.4/numarray/arraybase.h:27:
warning: useless type name in empty declaration

What's happening is that pyopengl is being built with
numarray, so is #including the numarray headers.

However, the numarray headers include a typedef on the
'Bool' type, and pyopengl has already included an X
header which does a #define on Bool:

X11/Xlib.h: #define Bool int

numarray/arraybase.h contains
typedef signed char Bool;

which GCC4 converts into:
typedef signed char int;

which causes the compile error.

Presumably the only reason that GCC3 is not affected is
due to a difference in the way that the GCC4
preprocessor can interact with typedef statements.

I realise that this header clash is actually nothing to
do with pyopengl directly, but as I've been unable to
find this problem occuring with other packages I
thought I'd come to you first. Any suggestions on the
real way to fix this, or at least who I should try
contacting?

Discussion

  • Logged In: NO

    Version 3.0.0a4 uses ctypes, and should not be subject
    to the problem, I would think.
    (That version requires numpy).