Quoting Emil Velikov (2017-12-12 07:04:09) > 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
I do appreciate it, I know you've dealt with a number of these problems already with the other build systems, and a number of the suggestions that you've made are very good ones that I should have done from the beginning, like just linking lmsensors to libgallium and being done with it. Dylan
signature.asc
Description: signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
