[Mesa-dev] [PATCH mesa] meson: add dep_thread to every lib that includes threads.h

[Emil Velikov]

On 7 December 2017 at 17:25, Dylan Baker <dylan at pnwbakers.com> wrote:
> Quoting Emil Velikov (2017-12-07 08:40:27)
>> On 7 December 2017 at 14:51, Eric Engestrom <eric.engestrom at imgtec.com> wrote:
>> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104141
>> > Signed-off-by: Eric Engestrom <eric.engestrom at imgtec.com>
>> > ---
>> >  src/broadcom/meson.build                    | 2 +-
>> >  src/gallium/auxiliary/meson.build           | 2 +-
>> >  src/gallium/state_trackers/nine/meson.build | 1 +
>> >  src/gallium/targets/xa/meson.build          | 2 +-
>> >  src/gallium/targets/xvmc/meson.build        | 2 +-
>> >  src/gbm/meson.build                         | 2 +-
>> >  src/intel/common/meson.build                | 2 +-
>> >  src/loader/meson.build                      | 2 +-
>> >  src/util/meson.build                        | 2 +-
>> >  9 files changed, 9 insertions(+), 8 deletions(-)
>> >
>> I doubt we can continue and pretend to be libpthread.so free.
>> To make it even funnier, depending on moon cycle or other fun factors,
>> we could get the pthread dependency implicitly satisfied as one of the
>> other shared libraries already pulls the library.
>>
>> So how about we simply append -pthread to CC/CXX with at global scope
>> and drop the all the individual dependencies?
>> It will safe us a few characters to type, plus will ensure that newly
>> added binaries don't fall victim of the same issue.
>
> Absolutely not. The meson build has dep_thread for a reason, because meson
> guarantees that calling `dependency('threads')` will always return the right
> value for your platform, even if that platform is windows and doesn't have
> pthreads at all (but does the right thing for cygwin).
>
I would recommend looking through clang/gcc. AFAICS any* platform/arch
combo supported by Mesa handles -pthread and that toggle does the
"right thing".
Obviously that can seem a bit hacky, so a better way to avoid all the
copy/paste is for meson to grow an option that allows folding the
required cflags/libs with the compiler directive.

> The reason that we're running into this problem is as you guessed that some
> dependencies pull in pthreads implicitly, for example LLVM, which is why we're
> seeing this so often in gallium.
>
Precisely. Due to the combinatoric explosions things are bound to
break again, hence my earlier suggestion.
I doubt you or anyone on the team will be excited to see things break.

-Emil

* I've checked Cygwin, Solaris-like, BSD-like, Linuxen, Hurd and
Android, on both 32 and 64bit x86, ARM and PPC.
I believe msys/mingw should be fine as well, but I'm short on details.