[Mesa-dev] [PATCH] travis: manually generate sys/syscall.h

[Eric Engestrom]

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.engestrom at 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.velikov at 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.engestrom at intel.com>

> 
> -- 
> Br,
> 
> Andres
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev