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. Dylan > > -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.
signature.asc
Description: signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
