From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: James Clark <james.clark@linaro.org>, Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
Adrian Hunter <adrian.hunter@intel.com>,
linux@leemhuis.info, linux-perf-users@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] perf tools: Fix in-source libperf build
Date: Tue, 29 Apr 2025 15:01:56 -0300 [thread overview]
Message-ID: <aBEUFK6o41mlkd9j@x1> (raw)
In-Reply-To: <20250429-james-perf-fix-libperf-in-source-build-v1-1-a1a827ac15e5@linaro.org>
On Tue, Apr 29, 2025 at 03:22:18PM +0100, James Clark wrote:
> When libperf is built alone in-source, $(OUTPUT) isn't set. This causes
> the generated uapi path to resolve to '/../arch' which results in a
> permissions error:
> mkdir: cannot create directory '/../arch': Permission denied
So this requires the only outstanding patch in perf-tools/perf-tools:
⬢ [acme@toolbx perf-tools-next]$ git log -5 --oneline perf-tools/perf-tools
bfb713ea53c746b0 (perf-tools/tmp.perf-tools, perf-tools/perf-tools, perf-tools) perf tools: Fix arm64 build by generating unistd_64.h
9c32cda43eb78f78 (tag: v6.15-rc3) Linux 6.15-rc3
ac71fabf15679fc7 gcc-15: work around sequence-point warning
05e8d261a34e5c63 gcc-15: add '__nonstring' markers to byte arrays
be913e7c4034bd7a gcc-15: get rid of misc extra NUL character padding
⬢ [acme@toolbx perf-tools-next]$
So probably should go to there, to be submitted to Linus in the current
merge window, right?
Namhyung?
- Arnaldo
> Fix it by removing the preceding '/..' which means that it gets
> generated either in the tools/lib/perf part of the tree or the OUTPUT
> folder. Some other rules that rely on OUTPUT further refine this
> conditionally depending on whether it's an in-source or out-of-source
> build, but I don't think we need the extra complexity here. And this
> rule is slightly different to others because the header is needed by
> both libperf and Perf. This is further complicated by the fact that Perf
> always passes O=... to libperf even for in source builds, meaning that
> OUTPUT isn't set consistently between projects.
>
> Because we're no longer going one level up to try to generate the file
> in the tools/ folder, Perf's include rule needs to descend into libperf.
> Also fix the clean rule while we're here.
>
> Reported-by: Thorsten Leemhuis <linux@leemhuis.info>
> Closes: https://lore.kernel.org/linux-perf-users/7703f88e-ccb7-4c98-9da4-8aad224e780f@leemhuis.info/
> Fixes: bfb713ea53c7 ("perf tools: Fix arm64 build by generating unistd_64.h")
> Signed-off-by: James Clark <james.clark@linaro.org>
> ---
> tools/lib/perf/Makefile | 6 +++---
> tools/perf/Makefile.config | 2 +-
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/tools/lib/perf/Makefile b/tools/lib/perf/Makefile
> index 1a19b5013f45..7fbb50b74c00 100644
> --- a/tools/lib/perf/Makefile
> +++ b/tools/lib/perf/Makefile
> @@ -42,7 +42,7 @@ libdir_relative_SQ = $(subst ','\'',$(libdir_relative))
> TEST_ARGS := $(if $(V),-v)
>
> INCLUDES = \
> --I$(OUTPUT)/../arch/$(SRCARCH)/include/generated/uapi \
> +-I$(OUTPUT)arch/$(SRCARCH)/include/generated/uapi \
> -I$(srctree)/tools/lib/perf/include \
> -I$(srctree)/tools/lib/ \
> -I$(srctree)/tools/include \
> @@ -100,7 +100,7 @@ $(LIBAPI)-clean:
> $(call QUIET_CLEAN, libapi)
> $(Q)$(MAKE) -C $(LIB_DIR) O=$(OUTPUT) clean >/dev/null
>
> -uapi-asm := $(OUTPUT)/../arch/$(SRCARCH)/include/generated/uapi/asm
> +uapi-asm := $(OUTPUT)arch/$(SRCARCH)/include/generated/uapi/asm
> ifeq ($(SRCARCH),arm64)
> syscall-y := $(uapi-asm)/unistd_64.h
> endif
> @@ -130,7 +130,7 @@ all: fixdep
> clean: $(LIBAPI)-clean
> $(call QUIET_CLEAN, libperf) $(RM) $(LIBPERF_A) \
> *.o *~ *.a *.so *.so.$(VERSION) *.so.$(LIBPERF_VERSION) .*.d .*.cmd tests/*.o LIBPERF-CFLAGS $(LIBPERF_PC) \
> - $(TESTS_STATIC) $(TESTS_SHARED)
> + $(TESTS_STATIC) $(TESTS_SHARED) $(syscall-y)
>
> TESTS_IN = tests-in.o
>
> diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
> index a52482654d4b..b7769a22fe1a 100644
> --- a/tools/perf/Makefile.config
> +++ b/tools/perf/Makefile.config
> @@ -29,7 +29,7 @@ include $(srctree)/tools/scripts/Makefile.arch
> $(call detected_var,SRCARCH)
>
> CFLAGS += -I$(OUTPUT)arch/$(SRCARCH)/include/generated
> -CFLAGS += -I$(OUTPUT)arch/$(SRCARCH)/include/generated/uapi
> +CFLAGS += -I$(OUTPUT)libperf/arch/$(SRCARCH)/include/generated/uapi
>
> # Additional ARCH settings for ppc
> ifeq ($(SRCARCH),powerpc)
>
> ---
> base-commit: bfb713ea53c746b07ae69fe97fa9b5388e4f34f9
> change-id: 20250429-james-perf-fix-libperf-in-source-build-15609cc212aa
>
> Best regards,
> --
> James Clark <james.clark@linaro.org>
>
next prev parent reply other threads:[~2025-04-29 18:01 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-29 14:22 [PATCH] perf tools: Fix in-source libperf build James Clark
2025-04-29 16:57 ` Thorsten Leemhuis
2025-04-29 18:01 ` Arnaldo Carvalho de Melo [this message]
2025-04-29 19:31 ` Namhyung Kim
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aBEUFK6o41mlkd9j@x1 \
--to=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=irogers@google.com \
--cc=james.clark@linaro.org \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linux@leemhuis.info \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox