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

[Jeremy Huddleston]

On Apr 22, 2009, at 20:35, vmrsss wrote:

> On 23 Apr 2009, at 03:42, Jeremy Huddleston wrote:
>> 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.
>
> You're right about Cocoa of course.
>
>> 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.
>
>
> So, /usr/X11/libGL.dylib contains GLX and /System/Library/..../ 
> OpenGL/Libraries/libGL.dylib contains GL (as used by Cocoa)?

Not exactly.  Both are "GL" ... /System/Library/Frameworks/ 
OpenGL.framework/Libraries/libGL.dylib is CGL.  Our GLX libGL is a  
translation layer that translates GLX to CGL.

> I am confused, can you conjecture why if I replace the new  
> libGL.dylib with the one from 2.3.2.1 it all works?

Because of the way we used to implement libGL, it worked for you.  You  
were calling GL functions that were passed directly on to CGL by the  
old GLX libGL, so you just got lucky that we implemented it that way.

> OK, luck, but there must be a technical explanation too. I suppose  
> the system loads /usr/X11/lib/libGL.dylib in both cases, does it not?

It does, because you linked it that way, but the problem is that it  
shouldn't be linking against the GLX libGL because you are not using  
GLX.  You are using CGL.  You need to link against the correct library  
for it to work correctly (-fw OpenGL rather than -lGL).

> (Also, it's not me who do -lGL, but a complex configure system. In  
> fact, the gcc commandline contains both -fw OpenGL and -lGL. And  
> you're telling me that -lGL should not be there at all...  I'll try  
> to find out and see what happens if I remove -lGL.)

That is correct.

>> Can you please provide a specific instance of a GLX application  
>> that works with the old libGL but crashes with the new one?
>
> At this stage I dont know how to tell apart GLX applications from  
> applications which use Cocoa/OpenGL (but possibly load /usr/X11/lib/ 
> libGL.dylib): what I had done previously was to scan my disc for  
> applications which load /usr/X11/lib/libGL.dylib (to check which  
> ones worked and which did not). For instance I had found the crash  
> attached, which now looks to me exactly identical to the one we are  
> discussing. So I wonder, do I have any GLX application at all?

Well, one way to know is if it uses X11 or not.  When you open the  
application and the window is in the foreground, is X11 the active OSX  
application?

For instance, if I run mplayer, it will create a separate application  
in the dock for mplayer.  If I use '-vo x11', it will render through  
X11.

--Jeremy