* [PATCH] bpftool: use linux/types.h from source tree for profiler build
@ 2020-03-12 10:53 Tobias Klauser
2020-03-12 12:48 ` Quentin Monnet
2020-03-12 13:03 ` [PATCH bpf-next v2] " Tobias Klauser
0 siblings, 2 replies; 8+ messages in thread
From: Tobias Klauser @ 2020-03-12 10:53 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov
Cc: Song Liu, Yonghong Song, bpf, Alexei Starovoitov
When compiling bpftool on a system where the /usr/include/asm symlink
doesn't exist (e.g. on an Ubuntu system without gcc-multilib installed),
the build fails with:
CLANG skeleton/profiler.bpf.o
In file included from skeleton/profiler.bpf.c:4:
In file included from /usr/include/linux/bpf.h:11:
/usr/include/linux/types.h:5:10: fatal error: 'asm/types.h' file not found
#include <asm/types.h>
^~~~~~~~~~~~~
1 error generated.
make: *** [Makefile:123: skeleton/profiler.bpf.o] Error 1
This indicates that the build is using linux/types.h from system headers
instead of source tree headers.
To fix this, adjust the clang search path to include the necessary
headers from tools/testing/selftests/bpf/include/uapi and
tools/include/uapi. Also undef __bitwise in skeleton/profiler.h avoid
clashing with the empty definition in
tools/testing/selftests/bpf/include/uapi/linux/types.h.
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Song Liu <songliubraving@fb.com>
Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
tools/bpf/bpftool/Makefile | 5 ++++-
tools/bpf/bpftool/skeleton/profiler.h | 1 +
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/tools/bpf/bpftool/Makefile b/tools/bpf/bpftool/Makefile
index 20a90d8450f8..f294f6c1e795 100644
--- a/tools/bpf/bpftool/Makefile
+++ b/tools/bpf/bpftool/Makefile
@@ -120,7 +120,10 @@ $(OUTPUT)_bpftool: $(_OBJS) $(LIBBPF)
$(QUIET_LINK)$(CC) $(CFLAGS) $(LDFLAGS) -o $@ $(_OBJS) $(LIBS)
skeleton/profiler.bpf.o: skeleton/profiler.bpf.c
- $(QUIET_CLANG)$(CLANG) -I$(srctree)/tools/lib -g -O2 -target bpf -c $< -o $@
+ $(QUIET_CLANG)$(CLANG) \
+ -I$(srctree)/tools/include/uapi/ \
+ -I$(srctree)/tools/testing/selftests/bpf/include/uapi \
+ -I$(srctree)/tools/lib -g -O2 -target bpf -c $< -o $@
profiler.skel.h: $(OUTPUT)_bpftool skeleton/profiler.bpf.o
$(QUIET_GEN)$(OUTPUT)./_bpftool gen skeleton skeleton/profiler.bpf.o > $@
diff --git a/tools/bpf/bpftool/skeleton/profiler.h b/tools/bpf/bpftool/skeleton/profiler.h
index e03b53eae767..95358c0df5ef 100644
--- a/tools/bpf/bpftool/skeleton/profiler.h
+++ b/tools/bpf/bpftool/skeleton/profiler.h
@@ -27,6 +27,7 @@ enum {
true = 1,
};
+#undef __bitwise
#ifdef __CHECKER__
#define __bitwise__ __attribute__((bitwise))
#else
--
2.25.1
^ permalink raw reply related [flat|nested] 8+ messages in thread* Re: [PATCH] bpftool: use linux/types.h from source tree for profiler build
2020-03-12 10:53 [PATCH] bpftool: use linux/types.h from source tree for profiler build Tobias Klauser
@ 2020-03-12 12:48 ` Quentin Monnet
2020-03-12 12:54 ` Tobias Klauser
2020-03-12 13:03 ` [PATCH bpf-next v2] " Tobias Klauser
1 sibling, 1 reply; 8+ messages in thread
From: Quentin Monnet @ 2020-03-12 12:48 UTC (permalink / raw)
To: Tobias Klauser, Daniel Borkmann, Alexei Starovoitov
Cc: Song Liu, Yonghong Song, bpf, Alexei Starovoitov
2020-03-12 11:53 UTC+0100 ~ Tobias Klauser <tklauser@distanz.ch>
> When compiling bpftool on a system where the /usr/include/asm symlink
> doesn't exist (e.g. on an Ubuntu system without gcc-multilib installed),
> the build fails with:
>
> CLANG skeleton/profiler.bpf.o
> In file included from skeleton/profiler.bpf.c:4:
> In file included from /usr/include/linux/bpf.h:11:
> /usr/include/linux/types.h:5:10: fatal error: 'asm/types.h' file not found
> #include <asm/types.h>
> ^~~~~~~~~~~~~
> 1 error generated.
> make: *** [Makefile:123: skeleton/profiler.bpf.o] Error 1
>
> This indicates that the build is using linux/types.h from system headers
> instead of source tree headers.
>
> To fix this, adjust the clang search path to include the necessary
> headers from tools/testing/selftests/bpf/include/uapi and
> tools/include/uapi. Also undef __bitwise in skeleton/profiler.h avoid
> clashing with the empty definition in
> tools/testing/selftests/bpf/include/uapi/linux/types.h.
>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
> Cc: Song Liu <songliubraving@fb.com>
> Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
> diff --git a/tools/bpf/bpftool/skeleton/profiler.h b/tools/bpf/bpftool/skeleton/profiler.h
> index e03b53eae767..95358c0df5ef 100644
> --- a/tools/bpf/bpftool/skeleton/profiler.h
> +++ b/tools/bpf/bpftool/skeleton/profiler.h
> @@ -27,6 +27,7 @@ enum {
> true = 1,
> };
>
> +#undef __bitwise
> #ifdef __CHECKER__
> #define __bitwise__ __attribute__((bitwise))
> #else
>
Even with the #undef above, I get warnings on __bitwise being redefined
in tools/testing/selftests/bpf/include/uapi/linux/types.h. Can we maybe
just find another name (or number of underscores) for the macro in
skeleton/profiler.h?
Makefile change works well otherwise, thanks (tested on Ubuntu with and
without gcc-multilib).
Quentin
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [PATCH] bpftool: use linux/types.h from source tree for profiler build
2020-03-12 12:48 ` Quentin Monnet
@ 2020-03-12 12:54 ` Tobias Klauser
0 siblings, 0 replies; 8+ messages in thread
From: Tobias Klauser @ 2020-03-12 12:54 UTC (permalink / raw)
To: Quentin Monnet
Cc: Daniel Borkmann, Alexei Starovoitov, Song Liu, Yonghong Song,
bpf, Alexei Starovoitov
On 2020-03-12 at 13:48:21 +0100, Quentin Monnet <quentin@isovalent.com> wrote:
> 2020-03-12 11:53 UTC+0100 ~ Tobias Klauser <tklauser@distanz.ch>
> > When compiling bpftool on a system where the /usr/include/asm symlink
> > doesn't exist (e.g. on an Ubuntu system without gcc-multilib installed),
> > the build fails with:
> >
> > CLANG skeleton/profiler.bpf.o
> > In file included from skeleton/profiler.bpf.c:4:
> > In file included from /usr/include/linux/bpf.h:11:
> > /usr/include/linux/types.h:5:10: fatal error: 'asm/types.h' file not found
> > #include <asm/types.h>
> > ^~~~~~~~~~~~~
> > 1 error generated.
> > make: *** [Makefile:123: skeleton/profiler.bpf.o] Error 1
> >
> > This indicates that the build is using linux/types.h from system headers
> > instead of source tree headers.
> >
> > To fix this, adjust the clang search path to include the necessary
> > headers from tools/testing/selftests/bpf/include/uapi and
> > tools/include/uapi. Also undef __bitwise in skeleton/profiler.h avoid
> > clashing with the empty definition in
> > tools/testing/selftests/bpf/include/uapi/linux/types.h.
> >
> > Cc: Daniel Borkmann <daniel@iogearbox.net>
> > Cc: Song Liu <songliubraving@fb.com>
> > Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>
> > Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
>
> > diff --git a/tools/bpf/bpftool/skeleton/profiler.h b/tools/bpf/bpftool/skeleton/profiler.h
> > index e03b53eae767..95358c0df5ef 100644
> > --- a/tools/bpf/bpftool/skeleton/profiler.h
> > +++ b/tools/bpf/bpftool/skeleton/profiler.h
> > @@ -27,6 +27,7 @@ enum {
> > true = 1,
> > };
> >
> > +#undef __bitwise
> > #ifdef __CHECKER__
> > #define __bitwise__ __attribute__((bitwise))
> > #else
> >
>
> Even with the #undef above, I get warnings on __bitwise being redefined
> in tools/testing/selftests/bpf/include/uapi/linux/types.h. Can we maybe
> just find another name (or number of underscores) for the macro in
> skeleton/profiler.h?
Good point. It seems I actually didn't test this properly. Will change
the typedefs to use the existing __bitwise__.
> Makefile change works well otherwise, thanks (tested on Ubuntu with and
> without gcc-multilib).
Thanks for testing.
- Tobias
^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH bpf-next v2] bpftool: use linux/types.h from source tree for profiler build
2020-03-12 10:53 [PATCH] bpftool: use linux/types.h from source tree for profiler build Tobias Klauser
2020-03-12 12:48 ` Quentin Monnet
@ 2020-03-12 13:03 ` Tobias Klauser
2020-03-12 14:15 ` Quentin Monnet
2020-03-12 17:59 ` Andrii Nakryiko
1 sibling, 2 replies; 8+ messages in thread
From: Tobias Klauser @ 2020-03-12 13:03 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov
Cc: Song Liu, Yonghong Song, bpf, Alexei Starovoitov, Quentin Monnet
When compiling bpftool on a system where the /usr/include/asm symlink
doesn't exist (e.g. on an Ubuntu system without gcc-multilib installed),
the build fails with:
CLANG skeleton/profiler.bpf.o
In file included from skeleton/profiler.bpf.c:4:
In file included from /usr/include/linux/bpf.h:11:
/usr/include/linux/types.h:5:10: fatal error: 'asm/types.h' file not found
#include <asm/types.h>
^~~~~~~~~~~~~
1 error generated.
make: *** [Makefile:123: skeleton/profiler.bpf.o] Error 1
This indicates that the build is using linux/types.h from system headers
instead of source tree headers.
To fix this, adjust the clang search path to include the necessary
headers from tools/testing/selftests/bpf/include/uapi and
tools/include/uapi. Also use __bitwise__ instead of __bitwise in
skeleton/profiler.h to avoid clashing with the definition in
tools/testing/selftests/bpf/include/uapi/linux/types.h.
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Song Liu <songliubraving@fb.com>
Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
tools/bpf/bpftool/Makefile | 5 ++++-
tools/bpf/bpftool/skeleton/profiler.h | 17 ++++++++---------
2 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/tools/bpf/bpftool/Makefile b/tools/bpf/bpftool/Makefile
index 20a90d8450f8..f294f6c1e795 100644
--- a/tools/bpf/bpftool/Makefile
+++ b/tools/bpf/bpftool/Makefile
@@ -120,7 +120,10 @@ $(OUTPUT)_bpftool: $(_OBJS) $(LIBBPF)
$(QUIET_LINK)$(CC) $(CFLAGS) $(LDFLAGS) -o $@ $(_OBJS) $(LIBS)
skeleton/profiler.bpf.o: skeleton/profiler.bpf.c
- $(QUIET_CLANG)$(CLANG) -I$(srctree)/tools/lib -g -O2 -target bpf -c $< -o $@
+ $(QUIET_CLANG)$(CLANG) \
+ -I$(srctree)/tools/include/uapi/ \
+ -I$(srctree)/tools/testing/selftests/bpf/include/uapi \
+ -I$(srctree)/tools/lib -g -O2 -target bpf -c $< -o $@
profiler.skel.h: $(OUTPUT)_bpftool skeleton/profiler.bpf.o
$(QUIET_GEN)$(OUTPUT)./_bpftool gen skeleton skeleton/profiler.bpf.o > $@
diff --git a/tools/bpf/bpftool/skeleton/profiler.h b/tools/bpf/bpftool/skeleton/profiler.h
index e03b53eae767..1f767e9510f7 100644
--- a/tools/bpf/bpftool/skeleton/profiler.h
+++ b/tools/bpf/bpftool/skeleton/profiler.h
@@ -32,16 +32,15 @@ enum {
#else
#define __bitwise__
#endif
-#define __bitwise __bitwise__
-typedef __u16 __bitwise __le16;
-typedef __u16 __bitwise __be16;
-typedef __u32 __bitwise __le32;
-typedef __u32 __bitwise __be32;
-typedef __u64 __bitwise __le64;
-typedef __u64 __bitwise __be64;
+typedef __u16 __bitwise__ __le16;
+typedef __u16 __bitwise__ __be16;
+typedef __u32 __bitwise__ __le32;
+typedef __u32 __bitwise__ __be32;
+typedef __u64 __bitwise__ __le64;
+typedef __u64 __bitwise__ __be64;
-typedef __u16 __bitwise __sum16;
-typedef __u32 __bitwise __wsum;
+typedef __u16 __bitwise__ __sum16;
+typedef __u32 __bitwise__ __wsum;
#endif /* __PROFILER_H */
--
2.25.1
^ permalink raw reply related [flat|nested] 8+ messages in thread* Re: [PATCH bpf-next v2] bpftool: use linux/types.h from source tree for profiler build
2020-03-12 13:03 ` [PATCH bpf-next v2] " Tobias Klauser
@ 2020-03-12 14:15 ` Quentin Monnet
2020-03-12 15:38 ` Daniel Borkmann
2020-03-12 17:59 ` Andrii Nakryiko
1 sibling, 1 reply; 8+ messages in thread
From: Quentin Monnet @ 2020-03-12 14:15 UTC (permalink / raw)
To: Tobias Klauser, Daniel Borkmann, Alexei Starovoitov
Cc: Song Liu, Yonghong Song, bpf, Alexei Starovoitov
2020-03-12 14:03 UTC+0100 ~ Tobias Klauser <tklauser@distanz.ch>
> When compiling bpftool on a system where the /usr/include/asm symlink
> doesn't exist (e.g. on an Ubuntu system without gcc-multilib installed),
> the build fails with:
>
> CLANG skeleton/profiler.bpf.o
> In file included from skeleton/profiler.bpf.c:4:
> In file included from /usr/include/linux/bpf.h:11:
> /usr/include/linux/types.h:5:10: fatal error: 'asm/types.h' file not found
> #include <asm/types.h>
> ^~~~~~~~~~~~~
> 1 error generated.
> make: *** [Makefile:123: skeleton/profiler.bpf.o] Error 1
>
> This indicates that the build is using linux/types.h from system headers
> instead of source tree headers.
>
> To fix this, adjust the clang search path to include the necessary
> headers from tools/testing/selftests/bpf/include/uapi and
> tools/include/uapi. Also use __bitwise__ instead of __bitwise in
> skeleton/profiler.h to avoid clashing with the definition in
> tools/testing/selftests/bpf/include/uapi/linux/types.h.
>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
> Cc: Song Liu <songliubraving@fb.com>
> Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>
> Cc: Quentin Monnet <quentin@isovalent.com>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Looks good, thanks!
Reviewed-by: Quentin Monnet <quentin@isovalent.com>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH bpf-next v2] bpftool: use linux/types.h from source tree for profiler build
2020-03-12 14:15 ` Quentin Monnet
@ 2020-03-12 15:38 ` Daniel Borkmann
0 siblings, 0 replies; 8+ messages in thread
From: Daniel Borkmann @ 2020-03-12 15:38 UTC (permalink / raw)
To: Quentin Monnet, Tobias Klauser, Alexei Starovoitov
Cc: Song Liu, Yonghong Song, bpf, Alexei Starovoitov
On 3/12/20 3:15 PM, Quentin Monnet wrote:
> 2020-03-12 14:03 UTC+0100 ~ Tobias Klauser <tklauser@distanz.ch>
>> When compiling bpftool on a system where the /usr/include/asm symlink
>> doesn't exist (e.g. on an Ubuntu system without gcc-multilib installed),
>> the build fails with:
>>
>> CLANG skeleton/profiler.bpf.o
>> In file included from skeleton/profiler.bpf.c:4:
>> In file included from /usr/include/linux/bpf.h:11:
>> /usr/include/linux/types.h:5:10: fatal error: 'asm/types.h' file not found
>> #include <asm/types.h>
>> ^~~~~~~~~~~~~
>> 1 error generated.
>> make: *** [Makefile:123: skeleton/profiler.bpf.o] Error 1
>>
>> This indicates that the build is using linux/types.h from system headers
>> instead of source tree headers.
>>
>> To fix this, adjust the clang search path to include the necessary
>> headers from tools/testing/selftests/bpf/include/uapi and
>> tools/include/uapi. Also use __bitwise__ instead of __bitwise in
>> skeleton/profiler.h to avoid clashing with the definition in
>> tools/testing/selftests/bpf/include/uapi/linux/types.h.
>>
>> Cc: Daniel Borkmann <daniel@iogearbox.net>
>> Cc: Song Liu <songliubraving@fb.com>
>> Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>
>> Cc: Quentin Monnet <quentin@isovalent.com>
>> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
>
> Looks good, thanks!
> Reviewed-by: Quentin Monnet <quentin@isovalent.com>
Applied, thanks (compiles fine over here as well now)!
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH bpf-next v2] bpftool: use linux/types.h from source tree for profiler build
2020-03-12 13:03 ` [PATCH bpf-next v2] " Tobias Klauser
2020-03-12 14:15 ` Quentin Monnet
@ 2020-03-12 17:59 ` Andrii Nakryiko
2020-03-12 18:38 ` Daniel Borkmann
1 sibling, 1 reply; 8+ messages in thread
From: Andrii Nakryiko @ 2020-03-12 17:59 UTC (permalink / raw)
To: Tobias Klauser
Cc: Daniel Borkmann, Alexei Starovoitov, Song Liu, Yonghong Song,
bpf, Alexei Starovoitov, Quentin Monnet
On Thu, Mar 12, 2020 at 6:04 AM Tobias Klauser <tklauser@distanz.ch> wrote:
>
> When compiling bpftool on a system where the /usr/include/asm symlink
> doesn't exist (e.g. on an Ubuntu system without gcc-multilib installed),
> the build fails with:
>
> CLANG skeleton/profiler.bpf.o
> In file included from skeleton/profiler.bpf.c:4:
> In file included from /usr/include/linux/bpf.h:11:
> /usr/include/linux/types.h:5:10: fatal error: 'asm/types.h' file not found
> #include <asm/types.h>
> ^~~~~~~~~~~~~
> 1 error generated.
> make: *** [Makefile:123: skeleton/profiler.bpf.o] Error 1
>
> This indicates that the build is using linux/types.h from system headers
> instead of source tree headers.
>
> To fix this, adjust the clang search path to include the necessary
> headers from tools/testing/selftests/bpf/include/uapi and
> tools/include/uapi. Also use __bitwise__ instead of __bitwise in
> skeleton/profiler.h to avoid clashing with the definition in
> tools/testing/selftests/bpf/include/uapi/linux/types.h.
>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
> Cc: Song Liu <songliubraving@fb.com>
> Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>
> Cc: Quentin Monnet <quentin@isovalent.com>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
> ---
> tools/bpf/bpftool/Makefile | 5 ++++-
> tools/bpf/bpftool/skeleton/profiler.h | 17 ++++++++---------
> 2 files changed, 12 insertions(+), 10 deletions(-)
>
> diff --git a/tools/bpf/bpftool/Makefile b/tools/bpf/bpftool/Makefile
> index 20a90d8450f8..f294f6c1e795 100644
> --- a/tools/bpf/bpftool/Makefile
> +++ b/tools/bpf/bpftool/Makefile
> @@ -120,7 +120,10 @@ $(OUTPUT)_bpftool: $(_OBJS) $(LIBBPF)
> $(QUIET_LINK)$(CC) $(CFLAGS) $(LDFLAGS) -o $@ $(_OBJS) $(LIBS)
>
> skeleton/profiler.bpf.o: skeleton/profiler.bpf.c
> - $(QUIET_CLANG)$(CLANG) -I$(srctree)/tools/lib -g -O2 -target bpf -c $< -o $@
> + $(QUIET_CLANG)$(CLANG) \
> + -I$(srctree)/tools/include/uapi/ \
> + -I$(srctree)/tools/testing/selftests/bpf/include/uapi \
Seems like I'm spoiling all the fun today :) But why are we ok with
bpftool build depending on selftests? This just makes it even harder
to have a stand-alone bpftool build eventually (similar to libbpf's
Github).
> + -I$(srctree)/tools/lib -g -O2 -target bpf -c $< -o $@
>
> profiler.skel.h: $(OUTPUT)_bpftool skeleton/profiler.bpf.o
> $(QUIET_GEN)$(OUTPUT)./_bpftool gen skeleton skeleton/profiler.bpf.o > $@
> diff --git a/tools/bpf/bpftool/skeleton/profiler.h b/tools/bpf/bpftool/skeleton/profiler.h
> index e03b53eae767..1f767e9510f7 100644
> --- a/tools/bpf/bpftool/skeleton/profiler.h
> +++ b/tools/bpf/bpftool/skeleton/profiler.h
> @@ -32,16 +32,15 @@ enum {
> #else
> #define __bitwise__
> #endif
> -#define __bitwise __bitwise__
>
> -typedef __u16 __bitwise __le16;
> -typedef __u16 __bitwise __be16;
> -typedef __u32 __bitwise __le32;
> -typedef __u32 __bitwise __be32;
> -typedef __u64 __bitwise __le64;
> -typedef __u64 __bitwise __be64;
> +typedef __u16 __bitwise__ __le16;
> +typedef __u16 __bitwise__ __be16;
> +typedef __u32 __bitwise__ __le32;
> +typedef __u32 __bitwise__ __be32;
> +typedef __u64 __bitwise__ __le64;
> +typedef __u64 __bitwise__ __be64;
>
> -typedef __u16 __bitwise __sum16;
> -typedef __u32 __bitwise __wsum;
> +typedef __u16 __bitwise__ __sum16;
> +typedef __u32 __bitwise__ __wsum;
>
> #endif /* __PROFILER_H */
> --
> 2.25.1
>
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [PATCH bpf-next v2] bpftool: use linux/types.h from source tree for profiler build
2020-03-12 17:59 ` Andrii Nakryiko
@ 2020-03-12 18:38 ` Daniel Borkmann
0 siblings, 0 replies; 8+ messages in thread
From: Daniel Borkmann @ 2020-03-12 18:38 UTC (permalink / raw)
To: Andrii Nakryiko, Tobias Klauser
Cc: Alexei Starovoitov, Song Liu, Yonghong Song, bpf,
Alexei Starovoitov, Quentin Monnet
On 3/12/20 6:59 PM, Andrii Nakryiko wrote:
> On Thu, Mar 12, 2020 at 6:04 AM Tobias Klauser <tklauser@distanz.ch> wrote:
>>
>> When compiling bpftool on a system where the /usr/include/asm symlink
>> doesn't exist (e.g. on an Ubuntu system without gcc-multilib installed),
>> the build fails with:
>>
>> CLANG skeleton/profiler.bpf.o
>> In file included from skeleton/profiler.bpf.c:4:
>> In file included from /usr/include/linux/bpf.h:11:
>> /usr/include/linux/types.h:5:10: fatal error: 'asm/types.h' file not found
>> #include <asm/types.h>
>> ^~~~~~~~~~~~~
>> 1 error generated.
>> make: *** [Makefile:123: skeleton/profiler.bpf.o] Error 1
>>
>> This indicates that the build is using linux/types.h from system headers
>> instead of source tree headers.
>>
>> To fix this, adjust the clang search path to include the necessary
>> headers from tools/testing/selftests/bpf/include/uapi and
>> tools/include/uapi. Also use __bitwise__ instead of __bitwise in
>> skeleton/profiler.h to avoid clashing with the definition in
>> tools/testing/selftests/bpf/include/uapi/linux/types.h.
>>
>> Cc: Daniel Borkmann <daniel@iogearbox.net>
>> Cc: Song Liu <songliubraving@fb.com>
>> Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>
>> Cc: Quentin Monnet <quentin@isovalent.com>
>> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
>> ---
>> tools/bpf/bpftool/Makefile | 5 ++++-
>> tools/bpf/bpftool/skeleton/profiler.h | 17 ++++++++---------
>> 2 files changed, 12 insertions(+), 10 deletions(-)
>>
>> diff --git a/tools/bpf/bpftool/Makefile b/tools/bpf/bpftool/Makefile
>> index 20a90d8450f8..f294f6c1e795 100644
>> --- a/tools/bpf/bpftool/Makefile
>> +++ b/tools/bpf/bpftool/Makefile
>> @@ -120,7 +120,10 @@ $(OUTPUT)_bpftool: $(_OBJS) $(LIBBPF)
>> $(QUIET_LINK)$(CC) $(CFLAGS) $(LDFLAGS) -o $@ $(_OBJS) $(LIBS)
>>
>> skeleton/profiler.bpf.o: skeleton/profiler.bpf.c
>> - $(QUIET_CLANG)$(CLANG) -I$(srctree)/tools/lib -g -O2 -target bpf -c $< -o $@
>> + $(QUIET_CLANG)$(CLANG) \
>> + -I$(srctree)/tools/include/uapi/ \
>> + -I$(srctree)/tools/testing/selftests/bpf/include/uapi \
>
> Seems like I'm spoiling all the fun today :) But why are we ok with
> bpftool build depending on selftests? This just makes it even harder
> to have a stand-alone bpftool build eventually (similar to libbpf's
> Github).
I suspect the Github copy of bpftool would have its own include infra like
in case of libbpf [0]?
Agree in any case that it's not an optimal situation with this dependency;
I suspect we might need the tools/testing/selftests/bpf/include/uapi/ under
tools/include/uapi/ in a proper way.
[0] https://github.com/libbpf/libbpf/tree/master/include
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2020-03-12 18:39 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-12 10:53 [PATCH] bpftool: use linux/types.h from source tree for profiler build Tobias Klauser
2020-03-12 12:48 ` Quentin Monnet
2020-03-12 12:54 ` Tobias Klauser
2020-03-12 13:03 ` [PATCH bpf-next v2] " Tobias Klauser
2020-03-12 14:15 ` Quentin Monnet
2020-03-12 15:38 ` Daniel Borkmann
2020-03-12 17:59 ` Andrii Nakryiko
2020-03-12 18:38 ` Daniel Borkmann
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).