[Mesa-dev] [PATCH mesa] meson: add dep_thread to every lib that includes threads.h

Tue Dec 12 20:02:35 UTC 2017

Quoting Emil Velikov (2017-12-12 07:04:09)
> On 11 December 2017 at 22:22, Dylan Baker <dylan at pnwbakers.com> wrote:
> > Quoting Emil Velikov (2017-12-11 12:06:35)
> >> On 7 December 2017 at 17:25, Dylan Baker <dylan at pnwbakers.com> wrote:
> >> > Quoting Emil Velikov (2017-12-07 08:40:27)
> >> >> On 7 December 2017 at 14:51, Eric Engestrom <eric.engestrom at imgtec.com> wrote:
> >> >> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104141
> >> >> > Signed-off-by: Eric Engestrom <eric.engestrom at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: signature
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20171212/0a2a4b34/attachment.sig>