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

[Emil Velikov]

On 11 December 2017 at 22:22, Dylan Baker <dylan at pnwbakers.com> wrote:
> Quoting Emil Velikov (2017-12-11 12:06:35)
>> 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.
>
> That's all fine, but the meson build is planning on supporting haiku and plain
> windows (with msvc), neither of which have pthreads (haiku does, but it's not a
> standalone library and you don't pass -pthreads to the compiler or linker and
> it's an error to do so). macOS clang also warns when passing -pthreads to the
> linker (but only the one shipped with xcode), not if you build clang yourself.
>
> If you feel strongly about it, open a bug upstream and discuss it with upstream.
> If they agree and add a mechanism to do so I'd be fine using it.
>
>> > 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.
>
> That's possible, obviously. I also think these sort of issues will work
> themselves out fairly quickly, while I'm very concerned adding -pthread into the
> list of arguments we pass unconditionally is going to break whole platforms in
> subtle and hard to fix ways, and really goes against the philosophy of meson,
> which is to solve these sort of problems in meson itself, rather than each build
> system solving them again and again, usually incorrectly.
>
> If we want to trot out the big hammer, I'd be happier just to add dep_thread to
> every shared library and binary than trying to add the right combination of
> -pthreads and -lpthreads for each platform ourselves to the C and C++ flags.
>
> There's about 350 uses of pthread symbols in mesa itself, of that there are 56
> unique files containing pthread symbols (some of which are generators), and of
> that there are only 23 unique folders containing pthread symbols. I think that
> getting this right is very doable.
>
> I'll start auditing the meson build to see if there's any place that we're
> missing passing pthreads directly.
>
Guess I should have made it more obvious:

I'm trying to save you (amongst others) the annoyance as things break
- since they will break :-(
It's entirely up-to you to decide on the best approach to mitigate or
even avoid that.

HTH
Emil