On Wed, 3 Feb 2010 14:02:45 -0700, Brian Brown <[email protected]> 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 [email protected]
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
_______________________________________________
PyQt mailing list [email protected]
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
