radv secure compile feature breaks compilation of RADV on armhf EABI (19.3-rc1)
The newly introduced feature "radv secure compile feature" break RADV compilation on armhf EABI.
Mesa 19.3-rc1 fails to compile on armhf because __NR_select syscall is not available on armhf EABI, only on OABI.
The attached patch radv_armhf.patch seems to properly solve the issue, since it compiles, and the resulting packages were able run a couple of vkrunnner tests. It was designed based on the discussion, following rule "(0) if defined, NR__newselect is always new select", at: https://patchwork.kernel.org/patch/9210735/ which states: "So I think we have the following behaviours:
(1) Define neither NR_select nor NR__newselect (and use pselect6 syscall for select): aarch64, openrisc, tilegx, unicore32, presumably any future arch
(2) only define NR__newselect, it is new select: mips, mips64, sh, s390
(3) Only define NR_select, want that to be new select: alpha, x86_64, s390x
(4) NR__newselect is new select, NR_select is old_select: i386, m68k, arm if kernel is not CONFIG_AEABI
(5) NR__newselect is new select, NR_select is defined but if called returns ENOSYS: microblaze, arm if CONFIG_AEABI, ppc64
(6) NR__newselect is new select, NR_select is a bonkers custom thing that tries to autodetect the calling convention: http://lxr.free-electrons.com/source/arch/powerpc/kernel/syscalls.c#L86 ppc32 (but only native 32-bit; 32-bit compat support on a ppc64 kernel is category 5, so I vote for ignoring this weirdness and calling ppc category 5)
(7) NR_select and NR__newselect are different numbers but both are new select: cris, sparc, sparc64
which is a pretty confusing mess, but I think it equates to: (0) if defined, NR__newselect is always new select (1) if NR_select is defined, the choices are: (a) NR_select is old_select: i386, m68k, arm (b) NR_select is defined but should ENOSYS: microblaze, ppc (c) NR_select defined and is new select: everything else (alpha, x86-64, s390x, cris, sparc, sparc64)