[Mesa-dev] [PATCH mesa] meson: add dep_thread to every lib that includes threads.h
dylan at pnwbakers.com
Thu Dec 7 17:25:30 UTC 2017
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).
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.
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 488 bytes
More information about the mesa-dev