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

[Dylan Baker]

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.

Dylan

> 
> -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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: signature
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20171211/650a0de6/attachment.sig>