On Tue, Apr 23, 2019 at 6:02 PM Daniel T. Lee <danieltim...@gmail.com> wrote:
>
> Oh, I've found what's the problem.
> About the files you've mentioned, nothing seems to matter on my system.
> But the problem is the order of the '-I' option matters.
>
> user@host:~/linux/samples/bpf $ make -n
>
> gcc -Wp,-MD,./samples/bpf/.sockex3_user.o.d -Wall
> -Wmissing-prototypes -Wstrict-prototypes \
> -O2 -fomit-frame-pointer -std=gnu89 -I./usr/include
> -I./tools/lib/ -I./tools/testing/selftests/bpf/ \
> -I./tools/ lib/ -I./tools/include -I./tools/perf -c -o
> ./samples/bpf/sockex3_user.o ./samples/bpf/sockex3_user.c;
> ...
> user@host:~/linux $ gcc -Wp,-MD,./samples/bpf/.sockex3_user.o.d
> -Wall -Wmissing-prototypes -Wstrict-prototypes \
> -O2 -fomit-frame-pointer -std=gnu89 -I./usr/include
> -I./tools/lib/ -I./tools/testing/selftests/bpf/ \
> -I./tools/ lib/ -I./tools/include -I./tools/perf -c -o
> ./samples/bpf/sockex3_user.o ./samples/bpf/sockex3_user.c;
>
> ./tools/lib/bpf/bpf.h:95:27: error: ‘UINT32_MAX’ undeclared here
> (not in a function); ...
> #define BPF_LOG_BUF_SIZE (UINT32_MAX >> 8) /* verifier maximum in
> kernels <= 5.1 */
> ^
> ./samples/bpf/bpf_load.h:31:25: note: in expansion of macro
> ‘BPF_LOG_BUF_SIZE’
> extern char bpf_log_buf[BPF_LOG_BUF_SIZE];
> ^~~~~~~~~~~~~~~~
>
> As you can see the dry make command in my system, the '-I./usr/include'
> option precedes than '-I./tools/include'. And in this situation, it
> gives an error.
> But when I switch these two options order, it runs successfully like below.
>
> user@host:~/linux $ gcc -Wp,-MD,./samples/bpf/.sockex3_user.o.d
> -Wall -Wmissing-prototypes -Wstrict-prototypes \
> -O2 -fomit-frame-pointer -std=gnu89 -I./tools/include
> -I./tools/lib/ -I./tools/testing/selftests/bpf/ \
> -I./tools/ lib/ -I./usr/include -I./tools/perf -c -o
> ./samples/bpf/sockex3_user.o ./samples/bpf/sockex3_user.c;
>
> // command runs successfully.
>
> Looks like when the '-I./usr/include' option precedes, it looks up for
> ./usr/include/linux/types.h. But when '-I./tools/include' comes up earlier,
> ./tools/include/linux/types.h header is used with compilation.
>
> Since these two <linux/types.h> headers are quite different, it causes an
> error.
> I'm not sure but perhaps the version difference of GNU Make is causing the
> inconsistency of the option order. (v4.1 on my system)
I have the same issue with v3.82 make.
We could adjust the include orders in samples/bpf/Makefile
KBUILD_HOSTCFLAGS += -I$(objtree)/usr/include
│······
KBUILD_HOSTCFLAGS += -I$(srctree)/tools/lib/
│······
KBUILD_HOSTCFLAGS += -I$(srctree)/tools/testing/selftests/bpf/
│······
KBUILD_HOSTCFLAGS += -I$(srctree)/tools/lib/
-I$(srctree)/tools/include │······
KBUILD_HOSTCFLAGS += -I$(srctree)/tools/perf
to switch $(objtree)/usr/include and $(srctree)/tools/include, but it
looks it has
some side effects on some other programs.
So your solution seems reasonable to me.
Acked-by: Yonghong Song <y...@fb.com>
