On Tuesday, 2018-07-24 19:44:14 +0300, Andres Gomez wrote: > On Tue, 2018-07-24 at 09:07 -0700, Dylan Baker wrote: > > Quoting Emil Velikov (2018-07-24 08:56:55) > > > On 24 July 2018 at 11:29, Eric Engestrom <eric.engest...@intel.com> wrote: > > > > On Thursday, 2018-07-19 15:33:33 +0300, Andres Gomez wrote: > > > > > Until now, the needed bits were wrongly included in linux/memfd.h > > > > > > > > > > Since Travis' sys/syscall.h doesn't provide the SYS_memfd_create, we > > > > > > The definition has moved across libc versions. Initially it was in > > > memfd.h these days it's in bits/syscall.h > > > > > > > Isn't this a matter of libc version? Isn't the right fix to upgrade the > > > > libc in the container instead of faking its files? > > > > > > > > > > Last time I've looked either a) updated package wasn't available or b) > > > it required sudo true (no more container, bring the VM) > > > > > > > And if the libc required is quite recent, what we need is a fallback in > > > > the code to support older libc (possibly with some features missing), > > > > which this build failure rightly reports. > > > > > > > > > > Keep in mind that Travis uses Ubuntu Trusty, which isn't really a user > > > of mesa-git and nearly EOL. > > > Since this is a build testing only, I would stick with the "build > > > everything" mindset and vote in favour of this workaround. > > > > > > Please change the Fixes tag to 3228335b55c - the first user of > > > syscall.h. With that > > > Reviewed-by: Emil Velikov <emil.veli...@collabora.com> > > > > > > -Emil > > > > I prefer this approach as well as a short term fix. Perhaps a better long > > term > > solution would be to build our own docker image that contains a more > > realistic > > set of minimum versions for building current mesa than a 4 year old LTS (we > > could build off of 16.04 for example). > > I was going to answer in a similar fashion. Emil and Dylan have been > faster than me. Thanks, guys ☺ ! > > Yes, Trusty is quite old and to "properly" fix this we would have to > check that the macro exists (basically, check the kernel version > against which glibc was compiled, ugh!). > > What I could suggest is that, for the Intel driver, which is the > consumer of memfd_create, they may want to check for the existence of > the SYS_memfd_create in a way or another in configure.ac and meson ... > or better, add those bits to this series and land it (CCing Greg V): > https://patchwork.freedesktop.org/series/35931/ > > Specifically: > https://patchwork.freedesktop.org/patch/200450/ > > Additionally, yeah, I think we may have to check whether we want to > upgrade Travis CI to use Xenial instead of Trusty. > > In any case, I'll go ahead and push this as is (with the comment from > Emil). We can still revisit afterwards.
I'm convinced :) Acked-by: Eric Engestrom <eric.engest...@intel.com> > > -- > Br, > > Andres > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
