API headers from libbpf should not be accessed directly from the
library's source directory. Instead, they should be exported with "make
install_headers". Let's adjust perf's Makefile to install those headers
locally when building libbpf.
Signed-off-by: Quentin Monnet <redacted>
---
Note: Sending to bpf-next because it's directly related to libbpf, and
to similar patches merged through bpf-next, but maybe Arnaldo prefers to
take it?
---
tools/perf/Makefile.perf | 24 +++++++++++++-----------
1 file changed, 13 insertions(+), 11 deletions(-)
On Thu, Nov 4, 2021 at 7:02 PM Quentin Monnet [off-list ref] wrote:
API headers from libbpf should not be accessed directly from the
library's source directory. Instead, they should be exported with "make
install_headers". Let's adjust perf's Makefile to install those headers
locally when building libbpf.
Signed-off-by: Quentin Monnet <redacted>
---
Note: Sending to bpf-next because it's directly related to libbpf, and
to similar patches merged through bpf-next, but maybe Arnaldo prefers to
take it?
Arnaldo would know better how to thoroughly test it, so I'd prefer to
route this through perf tree. Any objections, Arnaldo?
From: Arnaldo Carvalho de Melo <hidden> Date: 2021-11-05 18:58:13
On November 5, 2021 3:38:50 PM GMT-03:00, Andrii Nakryiko [off-list ref] wrote:
On Thu, Nov 4, 2021 at 7:02 PM Quentin Monnet [off-list ref] wrote:
quoted
API headers from libbpf should not be accessed directly from the
library's source directory. Instead, they should be exported with "make
install_headers". Let's adjust perf's Makefile to install those headers
locally when building libbpf.
Signed-off-by: Quentin Monnet <redacted>
---
Note: Sending to bpf-next because it's directly related to libbpf, and
to similar patches merged through bpf-next, but maybe Arnaldo prefers to
take it?
Arnaldo would know better how to thoroughly test it, so I'd prefer to
route this through perf tree. Any objections, Arnaldo?
From: Arnaldo Carvalho de Melo <acme@kernel.org> Date: 2021-11-06 19:29:26
Em Fri, Nov 05, 2021 at 11:38:50AM -0700, Andrii Nakryiko escreveu:
On Thu, Nov 4, 2021 at 7:02 PM Quentin Monnet [off-list ref] wrote:
quoted
API headers from libbpf should not be accessed directly from the
library's source directory. Instead, they should be exported with "make
install_headers". Let's adjust perf's Makefile to install those headers
locally when building libbpf.
Signed-off-by: Quentin Monnet <redacted>
---
Note: Sending to bpf-next because it's directly related to libbpf, and
to similar patches merged through bpf-next, but maybe Arnaldo prefers to
take it?
Arnaldo would know better how to thoroughly test it, so I'd prefer to
route this through perf tree. Any objections, Arnaldo?
Preliminary testing passed for 'BUILD_BPF_SKEL=1' with without
LIBBPF_DYNAMIC=1 (using the system's libbpf-devel to build perf), so far
so good, so I tentatively applied it, will see with the full set of
containers.
Thanks!
- Arnaldo
From: Arnaldo Carvalho de Melo <acme@kernel.org> Date: 2021-11-06 20:12:57
Em Sat, Nov 06, 2021 at 04:29:16PM -0300, Arnaldo Carvalho de Melo escreveu:
Em Fri, Nov 05, 2021 at 11:38:50AM -0700, Andrii Nakryiko escreveu:
quoted
On Thu, Nov 4, 2021 at 7:02 PM Quentin Monnet [off-list ref] wrote:
quoted
API headers from libbpf should not be accessed directly from the
library's source directory. Instead, they should be exported with "make
install_headers". Let's adjust perf's Makefile to install those headers
locally when building libbpf.
Signed-off-by: Quentin Monnet <redacted>
---
Note: Sending to bpf-next because it's directly related to libbpf, and
to similar patches merged through bpf-next, but maybe Arnaldo prefers to
take it?
Arnaldo would know better how to thoroughly test it, so I'd prefer to
route this through perf tree. Any objections, Arnaldo?
Preliminary testing passed for 'BUILD_BPF_SKEL=1' with without
LIBBPF_DYNAMIC=1 (using the system's libbpf-devel to build perf), so far
so good, so I tentatively applied it, will see with the full set of
containers.
Because all the preliminary tests used O= to have that OUTPUT variable
set, when we do simply:
make -C tools/perf
it breaks:
⬢[acme@toolbox perf]$ make -C tools clean > /dev/null 2>&1
⬢[acme@toolbox perf]$ make JOBS=1 -C tools/perf
make: Entering directory '/var/home/acme/git/perf/tools/perf'
BUILD: Doing 'make -j1' parallel build
HOSTCC fixdep.o
HOSTLD fixdep-in.o
LINK fixdep
<SNIP ABI sync warnings>
Auto-detecting system features:
... dwarf: [ on ]
... dwarf_getlocations: [ on ]
... glibc: [ on ]
... libbfd: [ on ]
... libbfd-buildid: [ on ]
... libcap: [ on ]
... libelf: [ on ]
... libnuma: [ on ]
... numa_num_possible_cpus: [ on ]
... libperl: [ on ]
... libpython: [ on ]
... libcrypto: [ on ]
... libunwind: [ on ]
... libdw-dwarf-unwind: [ on ]
... zlib: [ on ]
... lzma: [ on ]
... get_cpuid: [ on ]
... bpf: [ on ]
... libaio: [ on ]
... libzstd: [ on ]
... disassembler-four-args: [ on ]
CC fd/array.o
LD fd/libapi-in.o
CC fs/fs.o
CC fs/tracing_path.o
CC fs/cgroup.o
LD fs/libapi-in.o
CC cpu.o
CC debug.o
CC str_error_r.o
LD libapi-in.o
AR libapi.a
CC exec-cmd.o
CC help.o
CC pager.o
CC parse-options.o
CC run-command.o
CC sigchain.o
CC subcmd-config.o
LD libsubcmd-in.o
AR libsubcmd.a
CC core.o
CC cpumap.o
CC threadmap.o
CC evsel.o
CC evlist.o
CC mmap.o
CC zalloc.o
CC xyarray.o
CC lib.o
LD libperf-in.o
AR libperf.a
make[2]: *** No rule to make target 'libbpf', needed by 'libbpf/libbpf.a'. Stop.
make[1]: *** [Makefile.perf:240: sub-make] Error 2
make: *** [Makefile:70: all] Error 2
make: Leaving directory '/var/home/acme/git/perf/tools/perf'
⬢[acme@toolbox perf]$
Trying to fix...
- Arnaldo
From: Arnaldo Carvalho de Melo <acme@kernel.org> Date: 2021-11-06 21:05:13
Em Sat, Nov 06, 2021 at 05:12:48PM -0300, Arnaldo Carvalho de Melo escreveu:
Em Sat, Nov 06, 2021 at 04:29:16PM -0300, Arnaldo Carvalho de Melo escreveu:
quoted
Em Fri, Nov 05, 2021 at 11:38:50AM -0700, Andrii Nakryiko escreveu:
quoted
On Thu, Nov 4, 2021 at 7:02 PM Quentin Monnet [off-list ref] wrote:
quoted
API headers from libbpf should not be accessed directly from the
library's source directory. Instead, they should be exported with "make
install_headers". Let's adjust perf's Makefile to install those headers
locally when building libbpf.
Signed-off-by: Quentin Monnet <redacted>
---
Note: Sending to bpf-next because it's directly related to libbpf, and
to similar patches merged through bpf-next, but maybe Arnaldo prefers to
take it?
Arnaldo would know better how to thoroughly test it, so I'd prefer to
route this through perf tree. Any objections, Arnaldo?
Preliminary testing passed for 'BUILD_BPF_SKEL=1' with without
LIBBPF_DYNAMIC=1 (using the system's libbpf-devel to build perf), so far
so good, so I tentatively applied it, will see with the full set of
containers.
Because all the preliminary tests used O= to have that OUTPUT variable
set, when we do simply:
make -C tools/perf
So I'll have to remove it now as my container builds test both O= and
in-place builds (make -C tools/perf), I know many people (Jiri for
instance) don't use O=.
I tried to fix this but run out of time today, visits arriving soon, so
I'll try to come back to this tomorrow early morning, to push what I
have in to Linus, that is blocked by this now :-\
- Arnaldo
it breaks:
⬢[acme@toolbox perf]$ make -C tools clean > /dev/null 2>&1
⬢[acme@toolbox perf]$ make JOBS=1 -C tools/perf
make: Entering directory '/var/home/acme/git/perf/tools/perf'
BUILD: Doing 'make -j1' parallel build
HOSTCC fixdep.o
HOSTLD fixdep-in.o
LINK fixdep
<SNIP ABI sync warnings>
Auto-detecting system features:
... dwarf: [ on ]
... dwarf_getlocations: [ on ]
... glibc: [ on ]
... libbfd: [ on ]
... libbfd-buildid: [ on ]
... libcap: [ on ]
... libelf: [ on ]
... libnuma: [ on ]
... numa_num_possible_cpus: [ on ]
... libperl: [ on ]
... libpython: [ on ]
... libcrypto: [ on ]
... libunwind: [ on ]
... libdw-dwarf-unwind: [ on ]
... zlib: [ on ]
... lzma: [ on ]
... get_cpuid: [ on ]
... bpf: [ on ]
... libaio: [ on ]
... libzstd: [ on ]
... disassembler-four-args: [ on ]
CC fd/array.o
LD fd/libapi-in.o
CC fs/fs.o
CC fs/tracing_path.o
CC fs/cgroup.o
LD fs/libapi-in.o
CC cpu.o
CC debug.o
CC str_error_r.o
LD libapi-in.o
AR libapi.a
CC exec-cmd.o
CC help.o
CC pager.o
CC parse-options.o
CC run-command.o
CC sigchain.o
CC subcmd-config.o
LD libsubcmd-in.o
AR libsubcmd.a
CC core.o
CC cpumap.o
CC threadmap.o
CC evsel.o
CC evlist.o
CC mmap.o
CC zalloc.o
CC xyarray.o
CC lib.o
LD libperf-in.o
AR libperf.a
make[2]: *** No rule to make target 'libbpf', needed by 'libbpf/libbpf.a'. Stop.
make[1]: *** [Makefile.perf:240: sub-make] Error 2
make: *** [Makefile:70: all] Error 2
make: Leaving directory '/var/home/acme/git/perf/tools/perf'
⬢[acme@toolbox perf]$
Trying to fix...
- Arnaldo
From: Arnaldo Carvalho de Melo <acme@kernel.org> Date: 2021-11-06 21:20:16
Em Sat, Nov 06, 2021 at 06:05:07PM -0300, Arnaldo Carvalho de Melo escreveu:
Em Sat, Nov 06, 2021 at 05:12:48PM -0300, Arnaldo Carvalho de Melo escreveu:
quoted
Em Sat, Nov 06, 2021 at 04:29:16PM -0300, Arnaldo Carvalho de Melo escreveu:
quoted
Em Fri, Nov 05, 2021 at 11:38:50AM -0700, Andrii Nakryiko escreveu:
quoted
On Thu, Nov 4, 2021 at 7:02 PM Quentin Monnet [off-list ref] wrote:
quoted
API headers from libbpf should not be accessed directly from the
library's source directory. Instead, they should be exported with "make
install_headers". Let's adjust perf's Makefile to install those headers
locally when building libbpf.
Signed-off-by: Quentin Monnet <redacted>
---
Note: Sending to bpf-next because it's directly related to libbpf, and
to similar patches merged through bpf-next, but maybe Arnaldo prefers to
take it?
Arnaldo would know better how to thoroughly test it, so I'd prefer to
route this through perf tree. Any objections, Arnaldo?
Preliminary testing passed for 'BUILD_BPF_SKEL=1' with without
LIBBPF_DYNAMIC=1 (using the system's libbpf-devel to build perf), so far
so good, so I tentatively applied it, will see with the full set of
containers.
Because all the preliminary tests used O= to have that OUTPUT variable
set, when we do simply:
make -C tools/perf
So I'll have to remove it now as my container builds test both O= and
in-place builds (make -C tools/perf), I know many people (Jiri for
instance) don't use O=.
I tried to fix this but run out of time today, visits arriving soon, so
I'll try to come back to this tomorrow early morning, to push what I
have in to Linus, that is blocked by this now :-\
What I have, with your patch, is at:
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tmp.perf/core
It has both patches, as its needed for the BUILD_BPF_SKEL=1 mode to
build correctly with/without LIBBPF_DYNAMIC=1.
- Arnaldo
- Arnaldo
quoted
it breaks:
⬢[acme@toolbox perf]$ make -C tools clean > /dev/null 2>&1
⬢[acme@toolbox perf]$ make JOBS=1 -C tools/perf
make: Entering directory '/var/home/acme/git/perf/tools/perf'
BUILD: Doing 'make -j1' parallel build
HOSTCC fixdep.o
HOSTLD fixdep-in.o
LINK fixdep
<SNIP ABI sync warnings>
Auto-detecting system features:
... dwarf: [ on ]
... dwarf_getlocations: [ on ]
... glibc: [ on ]
... libbfd: [ on ]
... libbfd-buildid: [ on ]
... libcap: [ on ]
... libelf: [ on ]
... libnuma: [ on ]
... numa_num_possible_cpus: [ on ]
... libperl: [ on ]
... libpython: [ on ]
... libcrypto: [ on ]
... libunwind: [ on ]
... libdw-dwarf-unwind: [ on ]
... zlib: [ on ]
... lzma: [ on ]
... get_cpuid: [ on ]
... bpf: [ on ]
... libaio: [ on ]
... libzstd: [ on ]
... disassembler-four-args: [ on ]
CC fd/array.o
LD fd/libapi-in.o
CC fs/fs.o
CC fs/tracing_path.o
CC fs/cgroup.o
LD fs/libapi-in.o
CC cpu.o
CC debug.o
CC str_error_r.o
LD libapi-in.o
AR libapi.a
CC exec-cmd.o
CC help.o
CC pager.o
CC parse-options.o
CC run-command.o
CC sigchain.o
CC subcmd-config.o
LD libsubcmd-in.o
AR libsubcmd.a
CC core.o
CC cpumap.o
CC threadmap.o
CC evsel.o
CC evlist.o
CC mmap.o
CC zalloc.o
CC xyarray.o
CC lib.o
LD libperf-in.o
AR libperf.a
make[2]: *** No rule to make target 'libbpf', needed by 'libbpf/libbpf.a'. Stop.
make[1]: *** [Makefile.perf:240: sub-make] Error 2
make: *** [Makefile:70: all] Error 2
make: Leaving directory '/var/home/acme/git/perf/tools/perf'
⬢[acme@toolbox perf]$
Trying to fix...
- Arnaldo
2021-11-06 18:20 UTC-0300 ~ Arnaldo Carvalho de Melo [off-list ref]
Em Sat, Nov 06, 2021 at 06:05:07PM -0300, Arnaldo Carvalho de Melo escreveu:
quoted
Em Sat, Nov 06, 2021 at 05:12:48PM -0300, Arnaldo Carvalho de Melo escreveu:
quoted
Em Sat, Nov 06, 2021 at 04:29:16PM -0300, Arnaldo Carvalho de Melo escreveu:
quoted
Em Fri, Nov 05, 2021 at 11:38:50AM -0700, Andrii Nakryiko escreveu:
quoted
On Thu, Nov 4, 2021 at 7:02 PM Quentin Monnet [off-list ref] wrote:
quoted
API headers from libbpf should not be accessed directly from the
library's source directory. Instead, they should be exported with "make
install_headers". Let's adjust perf's Makefile to install those headers
locally when building libbpf.
Signed-off-by: Quentin Monnet <redacted>
---
Note: Sending to bpf-next because it's directly related to libbpf, and
to similar patches merged through bpf-next, but maybe Arnaldo prefers to
take it?
Arnaldo would know better how to thoroughly test it, so I'd prefer to
route this through perf tree. Any objections, Arnaldo?
Preliminary testing passed for 'BUILD_BPF_SKEL=1' with without
LIBBPF_DYNAMIC=1 (using the system's libbpf-devel to build perf), so far
so good, so I tentatively applied it, will see with the full set of
containers.
Because all the preliminary tests used O= to have that OUTPUT variable
set, when we do simply:
make -C tools/perf
So I'll have to remove it now as my container builds test both O= and
in-place builds (make -C tools/perf), I know many people (Jiri for
instance) don't use O=.
I tried to fix this but run out of time today, visits arriving soon, so
I'll try to come back to this tomorrow early morning, to push what I
have in to Linus, that is blocked by this now :-\
What I have, with your patch, is at:
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tmp.perf/core
It has both patches, as its needed for the BUILD_BPF_SKEL=1 mode to
build correctly with/without LIBBPF_DYNAMIC=1.
Hi Arnaldo, thanks for the review and testing. Apologies, I missed that
the recipe for the $(LIBBPF_OUTPUT) directory was located under the
"ifdef BUILD_BPF_SKEL". I'm sending a v2 that will handle this case better.
Quentin
API headers from libbpf should not be accessed directly from the
library's source directory. Instead, they should be exported with "make
install_headers". Let's adjust perf's Makefile to install those headers
locally when building libbpf.
v2:
- Fix $(LIBBPF_OUTPUT) when $(OUTPUT) is null.
- Make sure the recipe for $(LIBBPF_OUTPUT) is not under a "ifdef".
Signed-off-by: Quentin Monnet <redacted>
---
tools/perf/Makefile.perf | 32 +++++++++++++++++++-------------
1 file changed, 19 insertions(+), 13 deletions(-)
From: Arnaldo Carvalho de Melo <acme@kernel.org> Date: 2021-11-07 15:30:14
Em Sun, Nov 07, 2021 at 12:24:45AM +0000, Quentin Monnet escreveu:
API headers from libbpf should not be accessed directly from the
library's source directory. Instead, they should be exported with "make
install_headers". Let's adjust perf's Makefile to install those headers
locally when building libbpf.
v2:
- Fix $(LIBBPF_OUTPUT) when $(OUTPUT) is null.
- Make sure the recipe for $(LIBBPF_OUTPUT) is not under a "ifdef".
Thanks for the prompt reply, now the cases where it was failing are
passing!
Best regards,
- Arnaldo