On Apr 22, 2009, at 18:17, vmrsss wrote:
Hello
Changed 3 hours ago by jeremyhu@… • status changed from new to closed • resolution set to worksforme Please bring this up on xquartz-dev for faster iteration and more eyes.
As required, I am bringing this to the developer list. Please find below my original report and attachment.
This bug report is vague and I can't really do anything about it without specifics.
Yes, that's right and I am aware of it. Unfortunately, I am not acquainted at all with XQuartz.
Please give me examples of applications that fail with the new libGL.
(OK, but let's postpone this a bit longer)
mplayer is not a good example as it's not using GLX. It's using OpenGL.framework directly.
Well, that cannot be, because as I link /usr/X11/lib/libGL.1.2.dylib to the new (resp old) dylib mplayer keeps crashing (resp works just fine)
The stack trace you provided for the mplayer crash clearly shows that it is not using the glx video output plugin. You may have built mplayer with glx support, but you're not using it when this crash happens.
I suppose the key here is to run
mplayer -vo macosx
That is what you're doing. That causes mplayer to not use glx.
(as eg mplayer -vo x11 works). Have you tried that? This activates vo_macosx.m which uses libGL, eg: "nm -a vo_macosx.o" list includes:
U _glBegin U _glBindTexture U _glClear U _glColor3f U _glColor4f U _glDepthMask U _glDisable U _glEnable U _glEnd U _glFlush U _glLoadIdentity U _glMatrixMode U _glOrtho U _glTexCoord2f U _glVertex2i U _glViewport
That's using GL, but it's not using GLX. The macosx output plugin for mplayer uses Cocoa. It has nothing to do with GLX. If you're linking the macosx vo plugin against /usr/X11/lib/libGL.dylib, then you should expect it to not work. The fact that it used to work was pure luck on your part. You want to do -fw OpenGL to link against the correct libGL... not -lGL.
Can it be that the dylib system get confused with different versions of libGL.1.2? I have just noticed something which is likely to be significant: the old libGL (the one which works) appears to link a libGL.dylib v1.0 from the OpenGL framework, while the new libGL, doesnt:
That's correct. We now dlopen() it instead. Can you please provide a specific instance of a GLX application that works with the old libGL but crashes with the new one?