On 19 December 2017 at 08:46, Brendan King <brendan.k...@imgtec.com> wrote:
>
>
> On 18/12/17 16:42, Emil Velikov wrote:
>>
>> On 18 December 2017 at 16:33, Eric Engestrom <eric.engest...@imgtec.com>
>> wrote:
>>>
>>> From: Brendan King <brendan.k...@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.k...@imgtec.com>
>>> Signed-off-by: Eric Engestrom <eric.engest...@imgtec.com>
>>> ---
>>> This issue was noticed in the PowerVR driver. It's unclear whether other
>>> DRI drivers are affected as well.
>>
>> Are you sure any of the extra patches isn't causing the issue?
>> Just checked the binary and the shared link is there.
>
> We use slibtool, as libtool no longer works for us (we cross build Mesa, and
> libtool fails when trying to re-link libraries). It may be that this patch
> fixes an slibtool specific issue. Although slibtool produces .la files, it
> doesn't use them itself.
>
> We carry another patch that fixes an slibtool issue. We found it wasn't
> possible to build Mesa with Wayland support using slibtool; the link of
> libEGL fails with multiple symbol definition errors.
>
I've mentioned this to Eric over IRC - but adding here for posterity.
I would suspect that issue to be similar in nature to the one here.
S does not parse the LT_INIT([disable-static]) hence, unless
explicitly annotated it produces both static and shared lib.
Above seemed to be the case, not too long ago. Now comes the speculation:
As it's creating a static lib - it pulls the static instance of A. In
this case - moving A to the final link stage (aka constructing shared
lib) leads it to pick the glapi DSO.
Quick way to confirm - annotated glapi as shared (only):
--- a/src/mapi/Makefile.am
+++ b/src/mapi/Makefile.am
@@ -77,6 +77,7 @@ shared_glapi_libglapi_la_LIBADD = \
$(PTHREAD_LIBS) \
$(SELINUX_LIBS)
shared_glapi_libglapi_la_LDFLAGS = \
+ -shared \
-no-undefined \
$(GC_SECTIONS) \
$(LD_NO_UNDEFINED)
-Emil
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
