[Development] [OS X/xcb] error: xp_attach_gl_context returned: 2 followed by hang during application exit

Agocs Laszlo laszlo.agocs at theqtcompany.com
Mon Mar 30 10:54:48 CEST 2015


The OpenGL libs (and potentially a number of other system libs) are not supposed to be runtime switchable. The exception is Windows, where Qt 5.4 introduced fully dynamic resolving for WGL/EGL/GL/GLES in the platform plugin. Other platforms may get similar features in the future, but OS X is unlikely to be one of them. Therefore the OS X makespecs will continue to pull in the GL frameworks in the foreseeable future.

Cheers,
Laszlo

________________________________________
From: development-bounces+laszlo.agocs=theqtcompany.com at qt-project.org <development-bounces+laszlo.agocs=theqtcompany.com at qt-project.org> on behalf of René J.V. Bertin <rjvbertin at gmail.com>
Sent: Monday, March 30, 2015 10:42 AM
Cc: Apple X11 Users' List; <development at qt-project.org>
Subject: Re: [Development] [OS X/xcb] error: xp_attach_gl_context       returned:       2 followed by hang during application exit

On Monday March 30 2015 08:15:09 Agocs Laszlo wrote:

Hi,

>That has nothing to do with the platform plugins. You will want to introduce your own makespecs, or at least start customizing the standard Mac one. See e.g. mkspecs/common/mac.conf. That's what pulls in the standard GL frameworks for both the Qt libs and the app makefiles generated by qmake.

I would argue that it depends on how the platform plugins are supposed to be used/usable. If the idea is that the user can load a different plugin in application X to have it render using a different platform, then yes, it has to do with the plugins and no, you cannot just rewrite the mkspec to cat for something linking to a different OpenGL library at runtime.

If the plugins are not supposed to be used like that (despite the -platform commandline option), then yes, I can patch mac.conf so that it references the correct OpenGL libraries. I haven't checked, but I have a hunch that I'd have to build all of Qt like that.

In the meantime, it does seem that things work well enough with the approach  followed. The palette looks odd (MSWindows 95 like?) but apart from that and the reported hang-on-exit I think that there's enough basic functionality for routine testing for instance.
It'll also give a nice tool to assess memory footprint (would it be smaller under X11) etc.

And of course text renders much better using Freetype/Fontconfig with the Infinality-Ultimate patches than using CoreText O:-)

R.
_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development



More information about the Development mailing list