Em Tue, Dec 06, 2022 at 02:22:15PM -0800, Ian Rogers escreveu: > On Tue, Dec 6, 2022 at 9:31 AM Arnaldo Carvalho de Melo <acme@xxxxxxxxxx> wrote: > > Em Tue, Dec 06, 2022 at 02:13:48PM -0300, Arnaldo Carvalho de Melo escreveu: > > I'm missing some detail, this isn't working, util/trace-event.c is still > > being built and linked. > > The python binding should be usable without tracepoints, in fact its > > first usage was just to have access to the perf metaevents, see > > tools/perf/python/twatch.py. > You're right. I'd assumed that if you were disabling libtraceevent > then you'd also disable python. To fix the issue above you can do: > --- a/tools/perf/util/python-ext-sources > +++ b/tools/perf/util/python-ext-sources > @@ -30,7 +30,6 @@ util/rblist.c > util/counts.c > util/print_binary.c > util/strlist.c > -util/trace-event.c > ../lib/rbtree.c > util/string.c > util/symbol_fprintf.c > but this needs making conditional (possibly in setup.py) on whether > libtraceevent is present or not. Ok, I fixed this by removing the util/trace-event.c file at setup.py time, and removing it from the list of dependencies for python.so build, etc. With what I have at tmp.perf/core I'm being able to build with combinations of: - Having or not libtraceevent-devel installed - Using NO_LIBTRACEEVENT=1 - The default build All mixed up, but I wasn't so judicious so far, we need to add an entry with NO_LIBTRACEVENT=1 to tools/perf/tests/, etc. One thing I'm doing now is testing with the container builds, and I'm afraid we have to delay deleting the in-kernel old copy of tools/lib/traceevent till distros that don't ship libtraceevent as a separate package are EOLed. We need in those cases to fallback to tools/lib/traceevent/, with a warning probably. I'm now updating my container build recipes to install libtraceevent-devel, when available, which isn't the case, for instance, for almalinux:8, the first I tried updating. Please take a look at: https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git/commit/?h=tmp.perf/core The HEAD for that branch has the list of changes I made to get this going. Also I have the feeling the warning about libtraceevent not being available should be made more proeminent and detailed in what gets removed if this new, important dependency isn't met... I agree removing libtraceevent and adding yet another dependency to building perf is important since the libtraceevent maintainers took the decision of having it moved away from the kernel sources, but since this has been a no-brainer for so long, the fallout of this decision may be noticeable. At least by now we have clear markings of where libtraceevent is used. Thanks, - Arnaldo
