Hi Dylan, The architecture name in Debian is definitely ppc64el (not ppc64le). However, it's the IBM Power platform (POWER8) running in little endian mode (which yes, is confusing).
https://wiki.debian.org/ppc64el https://wiki.debian.org/ArchiveQualification/ppc64el FWIW: Apparently there's free access to full VM's at http://openpower.ic.unicamp.br/minicloud/ for developers, which might prove useful if the build parts turn hairy. Note: Haven't requested one myself.. tho I was looking into doing so a few months ago). On Tue, 4 Dec 2018 at 07:11, Dylan Baker <dy...@pnwbakers.com> wrote: > Quoting Timo Aaltonen (2018-12-03 11:03:59) > > On 3.12.2018 20.54, Dylan Baker wrote: > > > Quoting Timo Aaltonen (2018-12-03 10:36:12) > > >> On 3.12.2018 20.25, Emil Velikov wrote: > > >>> On Mon, 3 Dec 2018 at 17:49, Dylan Baker <dy...@pnwbakers.com> > wrote: > > >>>> > > >>>> Quoting Emil Velikov (2018-12-03 07:54:38) > > >>>>> Hi all, > > >>>>> > > >>>>> On Thu, 29 Nov 2018 at 17:44, Emil Velikov < > emil.l.veli...@gmail.com> wrote: > > >>>>>> > > >>>>>> Hi all, > > >>>>>> > > >>>>>> I can see why people may opt to not use or maintain the autotools > build. > > >>>>>> Although I would kindly ask that we do not remove it just yet. > > >>>>>> > > >>>>>> In Mesa, we have different parts not used by different teams. As > such > > >>>>>> we tend to remove stuff when nobody is around to maintain it > anymore. > > >>>>>> > > >>>>>> That said, I'm planning to continue maintaining it and would > appreciate > > >>>>>> if we keep it in-tree. > > >>>>>> > > >>>>>> As people may be concerned about bugreports and alike we can > trivially > > >>>>>> add a warning (as configure is invoked) to forwards any issues to > my > > >>>>>> email. Additionally (or alternatively) we can have an autotools > bugzilla > > >>>>>> category with me as the default assignee. > > >>>>>> > > >>>>> > > >>>>> Seems like I failed to make things clear enough with earlier > message. > > >>>>> > > >>>>> There is _no_ expectation for anyone to touch or even look at > autotools. > > >>>>> Hence, my suggestion to have configure.ac point people to me in > case of issues. > > >>>>> > > >>>>> If people have CI that uses it - feel free to drop it. > > >>>>> > > >>>> > > >>>> I've tried to stay out of this discussion, because everyone knows > my opinion, > > >>>> and I feel I don't have much to add, however... > > >>>> > > >>>>> > > >>>>> That said, many have asked why I'd go through the pain of > maintaining it: > > >>>>> - Most Linux distributions have switched, but there'still a few > outstanding > > >>>>> - Non Linux distributions have not switched > > >>>> > > >>>> Haiku has at least :) > > >>>> > > >>> \o/ > > >> > > >> And Debian too (in experimental). Ubuntu will follow once the final is > > >> out and it build everywhere. There's a build failure on ppc64el, btw: > > >> > > >> > https://buildd.debian.org/status/fetch.php?pkg=mesa&arch=ppc64el&ver=18.3.0%7Erc5-1&stamp=1543575640&raw=0 > > >> > > >>>>> - The meson build is missing features, relative the autotools one > > >>>> > > >>>> The only feature that I know that meson does not have relative to > autotools is > > >>>> the gl mangling stuff (which is intentional, we'll add it if > someone shows up > > >>>> with a need for it). Everything else is either intentionally not > implemented > > >>>> (GLX TLS toggling for example, which meson hardcodes on for OSes > that support > > >>>> it, and off for those that don't). > > >>>> > > >>> On top of the TLS and symbol mangling (for which I agree) there is: > > >>> - disable direct glx - non linux people use this > > >> > > >> This seems to work, at least on Hurd: > > >> > > >> diff --git a/meson.build b/meson.build > > >> index 33f4e5ad3cf..90cc0bb3af2 100644 > > >> --- a/meson.build > > >> +++ b/meson.build > > >> @@ -53,6 +53,7 @@ with_tests = get_option('build-tests') > > >> with_valgrind = get_option('valgrind') > > >> with_libunwind = get_option('libunwind') > > >> with_asm = get_option('asm') > > >> +with_glx_direct= get_option('glx-direct') > > There should be a space between t and = > > > >> with_glx_read_only_text = get_option('glx-read-only-text') > > >> with_osmesa = get_option('osmesa') > > >> with_swr_arches = get_option('swr-arches') > > >> @@ -370,9 +371,6 @@ if with_glvnd > > >> endif > > >> endif > > >> > > >> -# TODO: toggle for this > > >> -with_glx_direct = true > > >> - > > >> if with_vulkan_icd_dir == '' > > >> with_vulkan_icd_dir = join_paths(get_option('datadir'), > 'vulkan/icd.d') > > >> endif > > >> diff --git a/meson_options.txt b/meson_options.txt > > >> index a1d5ab0e185..4d5f36bf33d 100644 > > >> --- a/meson_options.txt > > >> +++ b/meson_options.txt > > >> @@ -205,6 +205,12 @@ option( > > >> choices : ['auto', 'disabled', 'dri', 'xlib', 'gallium-xlib'], > > >> description : 'Build support for GLX platform' > > >> ) > > >> +option( > > >> + 'glx-direct', > > >> + type : 'boolean', > > >> + value : 'true', > > >> + description : 'Enable direct rendering in GLX and EGL for DRI' > > >> +) > > >> option( > > >> 'egl', > > >> type : 'combo', > > >> > > >> > > > > > > I'm glad that this actually worked :) I tried to wire up direct glx so > adding a > > > toggle would be easy if we needed it. Do you need this for Hurd Timo? > > > > Yep, it also needs -D_GNU_SOURCE which hopefully is fixed by this: > > > > --- a/meson.build > > +++ b/meson.build > > @@ -779,7 +779,7 @@ if cc.compiles('int foo(void) __attribut > > endif > > > > # TODO: this is very incomplete > > -if ['linux', 'cygwin'].contains(host_machine.system()) > > +if ['linux', 'linux-gnu', 'cygwin', > 'gnu'].contains(host_machine.system()) > > pre_args += '-D_GNU_SOURCE' > > endif > > Would you like to send those as patches and CC me on them, or would you > like me > to send them and CC you? We'll need to make sure we have fixes tags so > they get > pulled into stable as well presumably. > > > > > (to match configure.ac) > > > > And that ppc64el build fail might be because it for some reason doesn't > seem to get -DUSE_PPC64LE_ASM.. > > (assuming that should be ppc64le) We probably are missing an endian check, > I'll > look at that in a minute. > > Dylan > > > > > > > > > -- > > t > > > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > -- Stuart Young (aka Cefiar)
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
