netdev - Re: [PATCH] libbpf: fix samples/bpf build failure due to undefined UINT32

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAH3MdRVGRv4jU+U1KKDRN-K7CvM+361SV4z=PqE5xcFGkJeU7A@mail.gmail.com>
Date:   Tue, 23 Apr 2019 23:04:57 -0700
From:   Y Song <ys114321@...il.com>
To:     "Daniel T. Lee" <danieltimlee@...il.com>
Cc:     Daniel Borkmann <daniel@...earbox.net>,
        Alexei Starovoitov <ast@...nel.org>,
        netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH] libbpf: fix samples/bpf build failure due to undefined UINT32_MAX

On Tue, Apr 23, 2019 at 6:02 PM Daniel T. Lee <danieltimlee@...il.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@...t:~/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@...t:~/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@...t:~/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 <yhs@...com>