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-next>] [day] [month] [year] [list]
Date:   Sat, 5 Oct 2019 07:21:50 +0900
From:   "Daniel T. Lee" <danieltimlee@...il.com>
To:     bpf <bpf@...r.kernel.org>, xdp-newbies@...r.kernel.org,
        Daniel Borkmann <daniel@...earbox.net>,
        Alexei Starovoitov <ast@...nel.org>,
        netdev <netdev@...r.kernel.org>
Subject: samples/bpf not working?

Currently, building the bpf samples isn't working.
Running make from the directory 'samples/bpf' will just shows following
result without compiling any samples.

$ make
make -C ../../ /git/linux/samples/bpf/ BPF_SAMPLES_PATH=/git/linux/samples/bpf
make[1]: Entering directory '/git/linux'
  CALL    scripts/checksyscalls.sh
  CALL    scripts/atomic/check-atomics.sh
  DESCEND  objtool
make[1]: Leaving directory '/git/linux'
$ ls *kern.o
ls: cannot access '*kern.o': No such file or directory

By using 'git bisect', found the problem is derived from below commit.
commit 394053f4a4b3 ("kbuild: make single targets work more correctly")

> Currently, the single target build directly descends into the directory
> of the target. For example,
>
>     $ make foo/bar/baz.o
>
> ... directly descends into foo/bar/.
>
> On the other hand, the normal build usually descends one directory at
> a time, i.e. descends into foo/, and then foo/bar/.
>
> This difference causes some problems.
>
> [...]
>
> This commit fixes those problems by making the single target build
> descend in the same way as the normal build does.

Not familiar with kbuild, so I'm not sure why this led to build failure.
My humble guess is, samples/bpf/Makefile tries to run make from current
directory, 'sample/bpf', but somehow upper commit changed the way it works.

samples/bpf/Makefile:232
# Trick to allow make to be run from this directory
all:
        $(MAKE) -C ../../ $(CURDIR)/ BPF_SAMPLES_PATH=$(CURDIR)

I've tried to figure out the problem with 'make --trace', but not sure why
it's not working. Just a hunch with build directory.

Any ideas to fix this problem?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ