[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180327030613.hkp7hox3g4prnbsg@intel.com>
Date: Tue, 27 Mar 2018 11:06:13 +0800
From: "Du, Changbin" <changbin.du@...el.com>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc: "Du, Changbin" <changbin.du@...el.com>, shuah@...nel.org,
linux-kselftest@...r.kernel.org, linux-kernel@...r.kernel.org,
Daniel Borkmann <daniel@...earbox.net>, netdev@...r.kernel.org
Subject: Re: [PATCH 4/4] selftests/bpf: fix compiling errors
On Mon, Mar 26, 2018 at 08:02:30PM -0700, Alexei Starovoitov wrote:
> On Tue, Mar 27, 2018 at 10:20:10AM +0800, Du, Changbin wrote:
> > On Mon, Mar 26, 2018 at 07:55:13AM -0700, Alexei Starovoitov wrote:
> > > On Mon, Mar 26, 2018 at 05:23:28PM +0800, changbin.du@...el.com wrote:
> > > > Signed-off-by: Changbin Du <changbin.du@...el.com>
> > > > ---
> > > > tools/testing/selftests/bpf/Makefile | 5 +++--
> > > > 1 file changed, 3 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
> > > > index 5c43c18..dc0fdc8 100644
> > > > --- a/tools/testing/selftests/bpf/Makefile
> > > > +++ b/tools/testing/selftests/bpf/Makefile
> > > > @@ -10,7 +10,8 @@ ifneq ($(wildcard $(GENHDR)),)
> > > > GENFLAGS := -DHAVE_GENHDR
> > > > endif
> > > >
> > > > -CFLAGS += -Wall -O2 -I$(APIDIR) -I$(LIBDIR) -I$(GENDIR) $(GENFLAGS) -I../../../include
> > > > +CFLAGS += -Wall -O2 -I$(APIDIR) -I$(LIBDIR) -I$(GENDIR) $(GENFLAGS) \
> > > > + -I../../../include -I../../../../usr/include
> > > > LDLIBS += -lcap -lelf -lrt -lpthread
> > > >
> > > > # Order correspond to 'make run_tests' order
> > > > @@ -62,7 +63,7 @@ else
> > > > CPU ?= generic
> > > > endif
> > > >
> > > > -CLANG_FLAGS = -I. -I./include/uapi -I../../../include/uapi \
> > > > +CLANG_FLAGS = -I. -I./include/uapi -I../../../include/uapi -I../../../../usr/include \
> > > > -Wno-compare-distinct-pointer-types
> > >
> > > Nack.
> > > I suspect that will break the build for everyone else who's doing it in the directory
> > > itself instead of the outer one.
> > >
> >
> > This one? But I didn't see any problem.
>
> because the build was lucky and additional path ../../../../usr/include didn't point
> to a valid dir?
I am sorry but I don't understand why you mean *lucky*. Of cause, the path is valid.
> Please test with in-source and out-of-source builds.
>
agree.
--
Thanks,
Changbin Du
Powered by blists - more mailing lists