Summary: | pyopengl-2.0.1.09 does not compile with numarray-1.5.1 or swig-1.3.29 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Juergen Rose <rose> |
Component: | Current packages | Assignee: | Python Gentoo Team <python> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | bruno.roggeri, coldwind, dsd, jan.simons |
Priority: | High | ||
Version: | 2006.0 | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | hack |
Description
Juergen Rose
2006-06-24 12:46:30 UTC
Created attachment 97687 [details, diff]
hack
This is a hack I'm using locally for the time being.
The problem only occurs when you try to compile pyopengl when numarray is installed. GCC4 only.
X11/Xlib.h gets installed which #defines Bool to int, then a numarray include does:
typedef signed char Bool;
which the GCC4 preprocessor changes to:
typedef signed char int;
which just makes no sense (you can't redefine int!)
I'll hopefully contact numarray upstream about this in the next few days...
Hello,
I'd just like to mention that now that gcc 4 is in stable, this compilation failure also concerns the stable tree (with numarray-1.3.1 and pyopengl-2.0.0.44). I hit this today while following the gcc upgrade guide on a (mostly) stable system.
As this is in gnome dependencies (via pygtk if the opengl useflag is on), maybe it should be added to the gnome tracker (or better, fixed asap ! although I understand it may not be that easy if we need to refactor all numarray - or X !).
> I'll hopefully contact numarray upstream about this in the next few days...
Any news :-S ?
Both pyopengl and numarray are unmaintained upstream. numarray has been replaced by numpy which does not have this issue. However, porting an app from numarray to numpy isn't that straightfoward. pyopengl failed on me with default i686 stage3 install i added echo "dev-python/numarray ~x86" >> /etc/portage/package.keywords re emerged it then re emerged python with USE="-tk" then emerge --resume and pyopengl compiled thought i might need to add this i'm kinda a noob to gentoo so i hope it helps is this bug still valid with numarray-1.5.2? Yes, opyopengl-2.0.1.09-r1 still fails with this: reating build/temp.linux-i686-2.4/src/interface_util i686-pc-linux-gnu-gcc -pthread -fno-strict-aliasing -DNDEBUG -march=athlon-tbird -Os -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-i686-2.4/src/interface_util/interface_util.o In file included from /usr/include/python2.4/numarray/arrayobject.h:20, from src/interface_util/../config.h:163, from src/interface_util/interface_util.c:2: /usr/include/python2.4/numarray/arraybase.h:31: error: two or more data types in declaration specifiers /usr/include/python2.4/numarray/arraybase.h:31: warning: useless type name in empty declaration src/interface_util/interface_util.c: In function 'Numeric_PyObject_AsFloatArray': ... with numarray-1.5.2-r1 installed. Ok, put pyopengl-3.0.0_beta1 in the tree. Since PyOpenGL-3.x uses ctypes instead of swig, this problem is fixed. |