On 7 December 2017 at 17:25, Dylan Baker <dy...@pnwbakers.com> wrote: > 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). > 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. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
