[Xquartz-dev] libGL.1.2.dylib shipped with 2.3.3 RC5 makes applications crash

[Jeremy Huddleston]

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?