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. -- Br, Andres _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
