[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20170503.120634.1673036085707133455.davem@davemloft.net>
Date: Wed, 03 May 2017 12:06:34 -0400 (EDT)
From: David Miller <davem@...emloft.net>
To: ast@...com
Cc: daniel@...earbox.net, netdev@...r.kernel.org
Subject: Re: [PATCH net-next] selftests/bpf: get rid of -D__x86_64__
From: David Miller <davem@...emloft.net>
Date: Wed, 03 May 2017 09:52:51 -0400 (EDT)
> From: Alexei Starovoitov <ast@...com>
> Date: Tue, 2 May 2017 21:14:43 -0700
>
>> -D__x86_64__ workaround was used to make /usr/include/features.h
>> to follow expected path through the system include headers.
>> This is not portable.
>> Instead define dummy stubs.h which is used by 'clang -target bpf'
>>
>> Fixes: 6882804c916b ("selftests/bpf: add a test for overlapping packet range checks")
>> Signed-off-by: Alexei Starovoitov <ast@...nel.org>
>
> Applied, thanks for getting rid of this wart.
Actually, we're now back to the orignal problem I had on sparc.
The issue is that you cannot resolve the core kernel __u?? types
unless __sparc__ is properly defined.
In file included from /home/davem/src/GIT/net/tools/testing/selftests/bpf/test_pkt_access.c:8:
In file included from ../../../include/uapi/linux/bpf.h:10:
/usr/include/linux/types.h:27:9: error: unknown type name '__u16'
typedef __u16 __bitwise __le16;
^
We really have to do the change I mentioned the first time I brought
up this issue, which is to get this via a variable set in the
per-arch top-level Makefile
Thanks.
Powered by blists - more mailing lists