On 11 December 2017 at 22:22, Dylan Baker <dy...@pnwbakers.com> wrote: > Quoting Emil Velikov (2017-12-11 12:06:35) >> 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. > > 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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev