Quoting Emil Velikov (2017-12-07 08:40:27) > On 7 December 2017 at 14:51, Eric Engestrom <eric.engest...@imgtec.com> wrote: > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104141 > > Signed-off-by: Eric Engestrom <eric.engest...@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.
> -Emil
> _______________________________________________
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
signature.asc
Description: signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
