Em Tue, Jul 24, 2018 at 12:49:43PM +0200, Stefan Liebler escreveu: > In each case, the introduction of the subdirectory /usr/lib/include leads to > the regression that one can't build the glibc RPM for s390 anymore as gcc > can't find headers like stdbool.h. > Should bpf.h be moved to /usr/lib/perf/include/bpf/bpf.h?
Thanks for the report, yes, I agree with your analysis, breaking the assumptions of existing setups like that is not good, can you send a patch, including this analysis so that this gets documented in the project's git changeset history? I wonder if we even shouldn't go one extra step and have it in: /usr/lib/perf/bpf/include/bpf/bpf.h? That extra /bpf/ is to make it sure that everything below /usr/lib/perf/bpf/ is to be used in generating eBPF objects to be loaded via sys_bpf(), of which the "include/bpf" subdir and bpf.h are for basic BPF aspects such as the definition of maps, etc, while include/fmt/ (below /usr/lib/perf/bpf/) could be C inline functions to be used in .c files to generate eBPF ELF objects, and other function "libraries" could live in different directories in this hierarchy. One can think about /usr/lib/perf/something-else-that-requires-c-headers/ like if we decide to create shared objects to process tracepoint events obtained from the kernel in a pretty format by just using the tracefs metadata, where we would transform a .c file into something other than a eBPF ELF file. But yeah, to fix the problem you described we have to have it all under /usr/lib/perf/ - Arnaldo