Sandipan Das <sandi...@linux.ibm.com> writes: > On 03/08/20 4:32 pm, Michael Ellerman wrote: >> Sachin Sant <sach...@linux.vnet.ibm.com> writes: >>>> On 02-Aug-2020, at 10:58 PM, Sandipan Das <sandi...@linux.ibm.com> wrote: >>>> On 02/08/20 4:45 pm, Sachin Sant wrote: >>>>> pkey_exec_prot test from linuxppc merge branch (3f68564f1f5a) fails to >>>>> build due to following error: >>>>> >>>>> gcc -std=gnu99 -O2 -Wall -Werror >>>>> -DGIT_VERSION='"v5.8-rc7-1276-g3f68564f1f5a"' >>>>> -I/home/sachin/linux/tools/testing/selftests/powerpc/include -m64 >>>>> pkey_exec_prot.c >>>>> /home/sachin/linux/tools/testing/selftests/kselftest_harness.h >>>>> /home/sachin/linux/tools/testing/selftests/kselftest.h ../harness.c >>>>> ../utils.c -o >>>>> /home/sachin/linux/tools/testing/selftests/powerpc/mm/pkey_exec_prot >>>>> In file included from pkey_exec_prot.c:18: >>>>> /home/sachin/linux/tools/testing/selftests/powerpc/include/pkeys.h:34: >>>>> error: "SYS_pkey_mprotect" redefined [-Werror] >>>>> #define SYS_pkey_mprotect 386 >>>>> >>>>> In file included from /usr/include/sys/syscall.h:31, >>>>> from >>>>> /home/sachin/linux/tools/testing/selftests/powerpc/include/utils.h:47, >>>>> from >>>>> /home/sachin/linux/tools/testing/selftests/powerpc/include/pkeys.h:12, >>>>> from pkey_exec_prot.c:18: >>>>> /usr/include/bits/syscall.h:1583: note: this is the location of the >>>>> previous definition >>>>> # define SYS_pkey_mprotect __NR_pkey_mprotect >>>>> >>>>> commit 128d3d021007 introduced this error. >>>>> selftests/powerpc: Move pkey helpers to headers >>>>> >>>>> Possibly the # defines for sys calls can be retained in pkey_exec_prot.c >>>>> or >>>>> >>>> >>>> I am unable to reproduce this on the latest merge branch (HEAD at >>>> f59195f7faa4). >>>> I don't see any redefinitions in pkey_exec_prot.c either. >>>> >>> >>> I can still see this problem on latest merge branch. >>> I have following gcc version >>> >>> gcc version 8.3.1 20191121 >> >> What libc version? Or just the distro & version? > > Sachin observed this on RHEL 8.2 with glibc-2.28. > I couldn't reproduce it on Ubuntu 20.04 and Fedora 32 and both these distros > are using glibc-2.31.
OK odd. Usually it's newer glibc that hits this problem. I guess on RHEL 8.2 we're getting the asm-generic version? But that would be quite wrong if that's what's happening. cheers
