[Xcb] [PATCH pthread-stubs 0/4] Rework pthread-stubs design/implementation

[Emil Velikov]

On 3 November 2016 at 20:24, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> Hi all,
>
> A recent change (commit fa6db2f9c01 - list.m4: Add some new pthread symbols)
> lead to an interesting bugreport [1] which makes me think that the current
> pthread-stubs design isn't as robust (broken?) as one would expect.
>
> In brief: if there is a pthread-stubs library, one can end up using a
> mismatched API - if one uses dlopen with a binary which pulls a full pthreads
> implementation. That is because the weak symbols, as provided by the
> pthread-stubs DSO, get overridden.
>
> This has gone unnoticed because a) on most platforms pthread-stubs never
> creates a DSO and in the rare case where it does b) it's very uncommon to
> dlopen a binary which pulls a non-lightweight pthreads symbols, from a
> pthreads-stubs (linked) one.
>
>
> The only solutions that I can think of are:
>  1) make pthread-stubs "meta package" who's Cflags/Libs expand to the platform
> specific PTHREAD_{CFLAGS,LIBS} if the runtime does not provide lightweight
> pthread symbols, or
>  2) "kill off" pthread-stubs and let everyone
>  - handle the "do I need to link against pthreads or not" in their configure.ac
>  - link against the complete/full pthread API
>
Forgot to mention:

If people are uneasy with my proposal, we'll be forced to go for 2 +
full link for mesa (and libdrm even). Alternatively please roll a
release and let me know so that we can update mesa/libdrm accordingly.

Thanks
Emil