On Fri, Jul 19, 2024 at 11:32:08AM -0700, Andrii Nakryiko wrote: > On Tue, Jul 16, 2024 at 12:55 AM Jiri Olsa <olsajiri@xxxxxxxxx> wrote: > > > > On Mon, Jul 15, 2024 at 01:32:43PM -0700, Brian Norris wrote: > > > The 'fixdep' tool is used to post-process dependency files for various > > > reasons, and it runs after every object file generation command. This > > > even includes 'fixdep' itself. > > > > > > In Kbuild, this isn't actually a problem, because it uses a single > > > command to generate fixdep (a compile-and-link command on fixdep.c), and > > > afterward runs the fixdep command on the accompanying .fixdep.cmd file. > > > > > > In tools/ builds (which notably is maintained separately from Kbuild), > > > fixdep is generated in several phases: > > > > > > 1. fixdep.c -> fixdep-in.o > > > 2. fixdep-in.o -> fixdep > > > > > > Thus, fixdep is not available in the post-processing for step 1, and > > > instead, we generate .cmd files that look like: > > > > > > ## from tools/objtool/libsubcmd/.fixdep.o.cmd > > > # cannot find fixdep (/path/to/linux/tools/objtool/libsubcmd//fixdep) > > > [...] > > > > > > These invalid .cmd files are benign in some respects, but cause problems > > > in others (such as the linked reports). > > > > > > Because the tools/ build system is rather complicated in its own right > > > (and pointedly different than Kbuild), I choose to simply open-code the > > > rule for building fixdep, and avoid the recursive-make indirection that > > > produces the problem in the first place. > > > > > > Link: https://lore.kernel.org/all/Zk-C5Eg84yt6_nml@xxxxxxxxxx/ > > > Signed-off-by: Brian Norris <briannorris@xxxxxxxxxxxx> > > > --- > > > > > > (no changes since v3) > > > > > > Changes in v3: > > > - Drop unnecessary tools/build/Build > > > > Acked-by: Jiri Olsa <jolsa@xxxxxxxxxx> > > > > so usually Arnaldo takes changes for tools/build, Arnaldo, could you please take a look? > > but still there'are the tools/lib/bpf bits.. > > I think it should be fine for libbpf bits to go through Arnaldo's tree > and get back to bpf-next eventually. Unlikely that we'll have any > conflict in libbpf's Makefile specifically, we rarely change it. I got this series now in perf-tools-next, Thanks, - Arnaldo
