[PyQt] Problem with snapshot and OpenGL

[Philip J. Schneider]

>On Wed, 3 Feb 2010 14:02:45 -0700, Brian Brown <rbb at techgame.net> wrote:
>>  Here you go:
>>
>>  Downloads/demangle% c++filt
>>  __ZN20QGLFramebufferObject15blitFramebufferEPS_RK5QRectS0_S3_mm
>>
>>	QGLFramebufferObject::blitFramebuffer(QGLFramebufferObject*, QRect
>const&,
>>	QGLFramebufferObject*, QRect const&, unsigned long, unsigned long)
>>
>>
>>  Downloads/demangle% c++filt
>>  __ZN20QGLFramebufferObject15blitFramebufferEPS_RK5QRectS0_S3_jj
>>
>>	QGLFramebufferObject::blitFramebuffer(QGLFramebufferObject*, QRect
>const&,
>>	QGLFramebufferObject*, QRect const&, unsigned int, unsigned int)
>>
>>  Thanks to Shane and finding that command :)
>
>That implies that Qt is being built with GLenum and GLbitfield defined as
>unsigned long, but PyQt is being built as them defined as unsigned int.
>
>gl.h on my (32 bit) Mac defines them as being unsigned int. (I'd be
>surprised if it was any different on a 64 bit Mac.) What about your Mac?
>
>Phil
>_______________________________________________
>PyQt mailing list    PyQt at riverbankcomputing.com
>http://www.riverbankcomputing.com/mailman/listinfo/pyqt


Here's my experience:

- The binary install of Qt resulted in my getting that same "unsigned 
long" vs "unsigned int" failure when trying to run a PyQt opengl 
program. Name demangling showed me the same thing that Brian's 
reporting.

- I removed the binary SDK of Qt, and built and installed Qt from 
sources. Name demangling shows that the arguments for blitFrameBuffer 
match in the libraries.

- My gl.h shows both GLenum and GLbitfield as being "unsigned int".

I can now run PyQt opengl programs - no link errors, etc.

I'm on a 32-bit (Mac Mini) machine, running Mac OS X 10.6.2

I think it's reasonable to conclude that the Qt binary SDK may have 
been built with "unsigned long" for GLenum and/or GLbitfield. 
Otherwise, why would my Qt build from sources work, while the 
precompiled binary SDK fail, when linking?

-- Philip