Date:   Wed, 24 Apr 2019 10:01:51 +0900
From:   "Daniel T. Lee" <danieltimlee@...il.com>
To:     Y Song <ys114321@...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

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'm wondering which might be the best ways to handle this problem?
(Maybe adding a Make implicit rule for the option order?)

On Wed, Apr 24, 2019 at 8:27 AM Y Song <ys114321@...il.com> wrote:
>
> On Tue, Apr 23, 2019 at 1:26 PM Daniel T. Lee <danieltimlee@...il.com> wrote:
> >
> > Currently, building bpf samples will cause the following error.
> >
> >     ./tools/lib/bpf/bpf.h:132: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];
> >                              ^~~~~~~~~~~~~~~~
> >
> > Due to commit 4519efa6f8ea ("libbpf: fix BPF_LOG_BUF_SIZE off-by-one error")
> > hard-coded size of BPF_LOG_BUF_SIZE has been replaced with UINT32_MAX which is
> > defined in <stdint.h> header.
> >
> > Even with this change, bpf selftests are running fine since these are built
> > with clang and it includes header(-idirafter) from clang/6.0.0/include.
> > (it has <stdint.h>)
> >
> >     clang -I. -I./include/uapi -I../../../include/uapi -idirafter /usr/local/include -idirafter /usr/include \
> >     -idirafter /usr/lib/llvm-6.0/lib/clang/6.0.0/include -idirafter /usr/include/x86_64-linux-gnu \
> >     -Wno-compare-distinct-pointer-types -O2 -target bpf -emit-llvm -c progs/test_sysctl_prog.c -o - | \
> >     llc -march=bpf -mcpu=generic  -filetype=obj -o /linux/tools/testing/selftests/bpf/test_sysctl_prog.o
> >
> > But bpf samples are compiled with GCC, and it only searches and includes
> > headers declared at the target file. As '#include <stdint.h>' hasn't been
> > declared in tools/lib/bpf/bpf.h, it causes build failure of bpf samples.
> >
> >     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;
> >
> > This commit add declaration of '#include <stdint.h>' to tools/lib/bpf/bpf.h
> > to fix this problem.
> >
> > Signed-off-by: Daniel T. Lee <danieltimlee@...il.com>
> > ---
> >  tools/lib/bpf/bpf.h | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/tools/lib/bpf/bpf.h b/tools/lib/bpf/bpf.h
> > index ff2506fe6bd2..9593fec75652 100644
> > --- a/tools/lib/bpf/bpf.h
> > +++ b/tools/lib/bpf/bpf.h
> > @@ -26,6 +26,7 @@
> >  #include <linux/bpf.h>
> >  #include <stdbool.h>
> >  #include <stddef.h>
> > +#include <stdint.h>
>
> I my case, I have the following in /usr/include/linux/bpf.h:
>   #include <linux/types.h>
>   #include <linux/bpf_common.h>
>
> The <linux/bpf.h> is included in tools/lib/bpf/bpf.h.
>
> and at tools/include/linux/types.h, I got
> #include <stdbool.h>
> #include <stddef.h>
> #include <stdint.h>
>
> So I don't have any issues.
> Could you check your system whether any of the above files
> missing or mismatched during compilation process?
>
> >
> >  #ifdef __cplusplus
> >  extern "C" {
> > --
> > 2.17.1
> >

Powered by blists - more mailing lists