[Mesa-dev] [PATCH] egl: link libEGL against the dynamic version of libglapi

[Emil Velikov]

On 18 December 2017 at 16:33, Eric Engestrom <eric.engestrom at imgtec.com> wrote:
> From: Brendan King <Brendan.King at imgtec.com>
>
> DRI modules store the address of the dispatch table in a TLS variable,
> _glapi_tls_Dispatch.
>
> Changes to the way libEGL is built in d884d8d0077c16d459b1 resulted in
> it being statically linked against libglapi, and thus containing its own
> copy of _glapi_tls_Dispatch. The result was that some applications would
> fail to work (e.g. deqp-egl, which dynamically loads libEGL), due to the
> DRI module storing the dispatch table address in one copy of
> _glapi_tls_Dispatch, and libEGL obtaining the address from another copy
> of the variable.
>
> This applies to autotools builds with --enable-glx-tls (on by default),
> and Meson builds (unconditional).
>
> Fixes: d884d8d0077c16d459b1 "egl/dri: link directly to libglapi.so"
> Signed-off-by: Brendan King <Brendan.King at imgtec.com>
> Signed-off-by: Eric Engestrom <eric.engestrom at imgtec.com>
> ---
> This issue was noticed in the PowerVR driver. It's unclear whether other
> DRI drivers are affected as well.
> ---
As the issue described is a Slibtool bug, and the Meson mention it
misleading I'll amend the commit message and push later on today:


Note: the following happens only when using slibtool.
Since this is a very serious breakage, we will keep the workaround until a
better solution is available.

DRI modules store the address of the dispatch table in a TLS variable,
_glapi_tls_Dispatch.

Changes to the way libEGL is built in d884d8d0077c16d459b1 resulted in
it being statically linked against libglapi, and thus containing its own
copy of _glapi_tls_Dispatch. The result was that some applications would
fail to work (e.g. deqp-egl, which dynamically loads libEGL), due to the
DRI module storing the dispatch table address in one copy of
_glapi_tls_Dispatch, and libEGL obtaining the address from another copy
of the variable.

Fixes: ...
...
Reviewed-by: Emil Velikov <emil.velikov at collabora.com>

-Emil