X server 1.5.3-2 candidate

[Jon TURNEY]

Yaakov (Cygwin Ports) wrote:
> Of course, we only have the choice of the latter, but if swrast_dri.so
> is missing, the GLX (and SGI-GLX) extension is disabled.  So I prepared
> mesa-7.2-2 and tried building that module, but after fixing up the build
> system, I found that it wasn't so simple.  The build only links the
> module against libmesa.a (a convenience lib that becomes part of libGL),
> leaving several undefined references:
> 
> _glapi_Context
> _glapi_Dispatch
> _glapi_add_dispatch
> _glapi_check_multithread
> _glapi_get_context
> _glapi_get_dispatch_table_size
> _glapi_noop_enable_warnings
> _glapi_set_context
> _glapi_set_dispatch
> _glapi_set_warning_func
> 
> My understanding -- and I may be wrong -- is that these symbols are left
> undefined on purpose, because they are meant to be resolved by whatever
> loads the module.  That may be a DRI-enabled libGL, an X server, etc.
> But that doesn't work for us because DLLs must have all references
> resolved at link time.
> 
> So what to do?  All the X servers have GLX support, but if I were to
> resolve these symbols against e.g. XWin, then the other servers will
> crash trying to load it.  (Yes, I tried it.)  So while our libGL doesn't
> actually use the module, the only neutral solution was to link against
> all of libGL instead of just part of it, and at least on the surface it
> appears to work.

After doing some tracing into the server, and looking at the difference 
between the successful and failing remote cases, it seems that we really do 
have a direct context in the success case, whereas in the failure case we have 
an indirect context.

I think that due to your trick of linking dri_swrast.so with libGL, we have 
some duplicate symbols, as libGL provides glapi_Dispatch itself, but it's also 
defined in the server GLX code.

I think maybe creating the indirect context (which occurs deep inside swrast) 
isn't setting the instance of this symbol which the GLX functions dispatch 
through when we have an indirect context, instead they are dispatching through 
glapi_noop_table, hence the crash.

I tried to work around this by removing the files with duplicate symbols 
(glpapi.c and glthread.c) from the GLX code and linking XWin with libGL as 
well, which seems to work as far as running glgears goes...

(I still need to check that these files are actually functionally identical 
between xserver/GLX and mesa/glapi)

Attached is a rough patch

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cygwin-glx-crash-workaround.patch
URL: <http://cygwin.com/pipermail/cygwin-xfree/attachments/20081123/69201582/attachment.ksh>
-------------- next part --------------
--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/