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

[Jeremy Huddleston]

The problem is deeper than I though... It looks like mplayer doesn't  
use a plugin model for the different input/output/codecs... they link  
everything into one binary... glx and cgl can't exist in the same  
namespace.  Your only option for now is either --disable-gl to disable  
using the glx module or --disable-macosx to disable all of the macosx- 
foo... if you choose --disable-macosx, you'll run into problems... I  
just pushed some changes to macports svn to address that.

--Jeremy

On Apr 22, 2009, at 21:07, Jeremy Huddleston wrote:

> So... I looked at the mplayer source...
>
> The mplayer build system is fubar, and I don't want to try fixing  
> it.  They're using a common set of ldflags for everything  
> indiscriminately.
>
> gl_common.c is for GLX and is used for vo_gl and vo_gl2.   
> vo_macosx.m is for vo_macosx.  The former needs -lGL with no -fw  
> OpenGL, the latter needs -fw OpenGL with no -lGL.
>
> Feel free to send this info upstream and give me a bug number to  
> follow, but their build system is not clean enough for me to want to  
> try patching.
>
> On Apr 22, 2009, at 20:59, Jeremy Huddleston wrote:
>
>> Then the problem is much deeper in that it's trying to mix GLX and  
>> CGL at the same time.  My guess is that this is a complicated and  
>> incorrect set of #ifdefs... many applications have such problems,  
>> and I've been working with upstream developers to get them fixed as  
>> I've run into them.
>>
>> mplayer should have two output plugins for gl.  One is macosx which  
>> should be linked with '-fw OpenGL'; the other is glx which should  
>> be linked with -lGL.
>>
>> The fact that glXDestroyContext is referenced from a file called  
>> gl_common.c scares me because it seems that their "common GL" code  
>> actually isn't GL at all but GLX.  This is definitely an mplayer  
>> bug, so please file this issue upstream, and let me know the URL to  
>> the bug, so I can follow up with those developers.
>>
>> On Apr 22, 2009, at 20:49, vmrsss wrote:
>>
>>> PS. If I remove -lGL, linking fails because of
>>>
>>>> Undefined symbols:
>>>> "_glXChooseVisual", referenced from:
>>>>    _config in vo_gl.o
>>>> "_glXCreateContext", referenced from:
>>>>    _setGlWindow in gl_common.o
>>>> "_glXGetConfig", referenced from:
>>>>    _initGl in vo_gl2.o
>>>>    _initGl in vo_gl2.o
>>>>    _initGl in vo_gl2.o
>>>>    _initGl in vo_gl2.o
>>>>    _config in vo_gl2.o
>>>>    _config in vo_gl2.o
>>>>    _config in vo_gl2.o
>>>>    _config in vo_gl2.o
>>>>    _config in vo_gl2.o
>>>>    _config in vo_gl2.o
>>>>    _config in vo_gl2.o
>>>>    _config in vo_gl2.o
>>>>    _config in vo_gl2.o
>>>> "_glXSwapBuffers", referenced from:
>>>>    _swapGlBuffers in gl_common.o
>>>> "_glXDestroyContext", referenced from:
>>>>    _releaseGlContext in gl_common.o
>>>>    _setGlWindow in gl_common.o
>>>>    _setGlWindow in gl_common.o
>>>> "_glXMakeCurrent", referenced from:
>>>>    _releaseGlContext in gl_common.o
>>>>    _setGlWindow in gl_common.o
>>>
>>> which are not in /System/Library/Frameworks/OpenGL.framework/ 
>>> Libraries/libGL.dylib nor in OpenGL, apparently. (Sorry for being  
>>> so ignorant about all this...)
>>> _______________________________________________
>>> Xquartz-dev mailing list
>>> Xquartz-dev at lists.macosforge.org
>>> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
>>
>> _______________________________________________
>> Xquartz-dev mailing list
>> Xquartz-dev at lists.macosforge.org
>> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
>
> _______________________________________________
> Xquartz-dev mailing list
> Xquartz-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev