Re: [PATCH v4 2/3] tools build: Avoid circular .fixdep-in.o.cmd issues

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

>
> thanks,
> jirka
>
> >
> >  tools/build/Build    |  3 ---
> >  tools/build/Makefile | 11 ++---------
> >  2 files changed, 2 insertions(+), 12 deletions(-)
> >  delete mode 100644 tools/build/Build
> >
> > diff --git a/tools/build/Build b/tools/build/Build
> > deleted file mode 100644
> > index 76d1a4960973..000000000000
> > --- a/tools/build/Build
> > +++ /dev/null
> > @@ -1,3 +0,0 @@
> > -hostprogs := fixdep
> > -
> > -fixdep-y := fixdep.o
> > diff --git a/tools/build/Makefile b/tools/build/Makefile
> > index 17cdf01e29a0..fea3cf647f5b 100644
> > --- a/tools/build/Makefile
> > +++ b/tools/build/Makefile
> > @@ -43,12 +43,5 @@ ifneq ($(wildcard $(TMP_O)),)
> >       $(Q)$(MAKE) -C feature OUTPUT=$(TMP_O) clean >/dev/null
> >  endif
> >
> > -$(OUTPUT)fixdep-in.o: FORCE
> > -     $(Q)$(MAKE) $(build)=fixdep
> > -
> > -$(OUTPUT)fixdep: $(OUTPUT)fixdep-in.o
> > -     $(QUIET_LINK)$(HOSTCC) $(KBUILD_HOSTLDFLAGS) -o $@ $<
> > -
> > -FORCE:
> > -
> > -.PHONY: FORCE
> > +$(OUTPUT)fixdep: $(srctree)/tools/build/fixdep.c
> > +     $(QUIET_CC)$(HOSTCC) $(KBUILD_HOSTLDFLAGS) -o $@ $<
> > --
> > 2.45.2.993.g49e7a77208-goog
> >
> >
>





[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux