01 Sep, 2021
1 commit
-
Currently the clean target when using O= isn't cleaning the feature
detect output. This is because O= and OUTPUT= are set to canonical
paths. For example in tools/perf/Makefile:FULL_O := $(shell cd $(PWD); readlink -f $(O) || echo $(O))
This means that OUTPUT ends in a / and most usages prepend it to a file
without adding an extra /. This line that was changed adds an extra /
before the 'feature' folder but not to the end, resulting in a clean
command like this:rm -f /tmp/build//featuretest-all.bin ...
After the change the clean command looks like this:
rm -f /tmp/build/feature/test-all.bin ...
Fixes: 762323eb39a257c3 ("perf build: Move feature cleanup under tools/build")
Signed-off-by: James Clark
Acked-by: Jiri Olsa
Link: http://lore.kernel.org/lkml/20210816130705.1331868-1-james.clark@arm.com
Signed-off-by: Arnaldo Carvalho de Melo
07 Mar, 2021
1 commit
-
Arnaldo reported issue for following build command:
$ rm -rf /tmp/krava; mkdir /tmp/krava; make O=/tmp/krava clean
CLEAN config
/bin/sh: line 0: cd: /tmp/krava/feature/: No such file or directory
../../scripts/Makefile.include:17: *** output directory "/tmp/krava/feature/" does not exist. Stop.
make[1]: *** [Makefile.perf:1010: config-clean] Error 2
make: *** [Makefile:90: clean] Error 2The problem is that now that we include scripts/Makefile.include
in feature's Makefile (which is fine and needed), we need to ensure
the OUTPUT directory exists, before executing (out of tree) clean
command.Removing the feature's cleanup from perf Makefile and fixing
feature's cleanup under build Makefile, so it now checks that
there's existing OUTPUT directory before calling the clean.Fixes: 211a741cd3e1 ("tools: Factor Clang, LLC and LLVM utils definitions")
Reported-by: Arnaldo Carvalho de Melo
Signed-off-by: Jiri Olsa
Tested-by: Arnaldo Carvalho de Melo
Tested-by: Sedat Dilek # LLVM/Clang v13-git
Cc: Alexander Shishkin
Cc: Ian Rogers
Cc: Mark Rutland
Cc: Michael Petlan
Cc: Namhyung Kim
Cc: Peter Zijlstra
Link: http://lore.kernel.org/lkml/20210224150831.409639-1-jolsa@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
12 Nov, 2020
1 commit
-
Several Makefiles in tools/ need to define the host toolchain variables.
Move their definition to tools/scripts/Makefile.includeSigned-off-by: Jean-Philippe Brucker
Signed-off-by: Andrii Nakryiko
Acked-by: Jiri Olsa
Acked-by: Rafael J. Wysocki
Link: https://lore.kernel.org/bpf/20201110164310.2600671-2-jean-philippe@linaro.org
28 Aug, 2020
1 commit
-
The system for "Auto-detecting system features" located under
tools/build/ are (currently) used by perf, libbpf and bpftool. It can
contain stalled feature detection files, which are not cleaned up by
libbpf and bpftool on make clean (side-note: perf tool is correct).Fix this by making the users invoke the make clean target.
Some details about the changes. The libbpf Makefile already had a
clean-config target (which seems to be copy-pasted from perf), but this
target was not "connected" (a make dependency) to clean target. Choose
not to rename target as someone might be using it. Did change the output
from "CLEAN config" to "CLEAN feature-detect", to make it more clear
what happens.This is related to the complaint and troubleshooting in the following
link: https://lore.kernel.org/lkml/20200818122007.2d1cfe2d@carbon/Signed-off-by: Jesper Dangaard Brouer
Signed-off-by: Daniel Borkmann
Acked-by: Jiri Olsa
Link: https://lore.kernel.org/lkml/20200818122007.2d1cfe2d@carbon/
Link: https://lore.kernel.org/bpf/159851841661.1072907.13770213104521805592.stgit@firesoul
18 Jul, 2018
1 commit
-
In preparation for enabling command line LDFLAGS, re-name HOSTLDFLAGS
to KBUILD_HOSTLDFLAGS as the internal use only flags. This should not
have any visible effects.Signed-off-by: Laura Abbott
Signed-off-by: Masahiro Yamada
12 Jul, 2018
1 commit
-
The final link of fixdep uses LDFLAGS but not the existing HOSTLDFLAGS.
Fix this.Signed-off-by: Laura Abbott
Acked-by: Jiri Olsa
Signed-off-by: Masahiro Yamada
02 Nov, 2017
1 commit
-
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.By default all files without license information are under the default
license of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if
Reviewed-by: Philippe Ombredanne
Reviewed-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
18 Feb, 2017
1 commit
-
Ingo reported following build failure:
On Sat, Feb 11, 2017 at 12:12:34PM +0100, Ingo Molnar wrote:
>
> So I had this oldish 32-bit 15.10 Ubuntu installation around (fully updated), and
> trying to build perf gave me:
>
> deimos:~/tip/tools/perf> make
> BUILD: Doing 'make -j4' parallel build
> make[3]: *** No rule to make target '/usr/include/x86_64-linux-gnu/sys/types.h', needed by 'fixdep.o'. Stop.
> Makefile:42: recipe for target 'fixdep-in.o' failed
> make[2]: *** [fixdep-in.o] Error 2
> /home/mingo/tip/tools/build/Makefile.include:4: recipe for target 'fixdep' failed
> make[1]: *** [fixdep] Error 2
> Makefile:68: recipe for target 'all' failed
> make: *** [all] Error 2
>
> Now this got a bit better after I did a 'make mrproper' in the kernel tree:
>
> deimos:~/tip/tools/perf> make
> BUILD: Doing 'make -j4' parallel build
> HOSTCC fixdep.o
> /home/mingo/tip/tools/build/fixdep: 1: /home/mingo/tip/tools/build/fixdep: Syntax error: "(" unexpected
> /home/mingo/tip/tools/build/Makefile.build:101: recipe for target 'fixdep.o' failed
> make[3]: *** [fixdep.o] Error 2
> Makefile:42: recipe for target 'fixdep-in.o' failed
> make[2]: *** [fixdep-in.o] Error 2
> /home/mingo/tip/tools/build/Makefile.include:4: recipe for target 'fixdep' failed
> make[1]: *** [fixdep] Error 2
> Makefile:68: recipe for target 'all' failed
> make: *** [all] Error 2
>
> After some digging it turns out that my 'fixdep' binary was 64-bit:
>
> deimos:~/tip/tools/perf> file /home/mingo/tip/tools/build/fixdep
> /home/mingo/tip/tools/build/fixdep: ELF 64-bit LSB executable, x86-64, version 1
> (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux
> 2.6.32, BuildID[sha1]=d527f736b57b5ba47210fbcb562a3b52867d21c1, not stripped
>
> But it did not get cleaned out by 'make clean'.
>
> Only after I did a 'make clean' in tools/ itself, did it get built properly.It shows we don't clean up properly the fixdep objects, so adding
special rule for that.Signed-off-by: Jiri Olsa
Reported-by: Ingo Molnar
Cc: David Ahern
Cc: Namhyung Kim
Cc: Peter Zijlstra
Link: http://lkml.kernel.org/r/1487340058-10496-2-git-send-email-jolsa@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
11 Dec, 2016
1 commit
-
make already provides the current working directory in a variable, so make
use of it instead of forking a shell. Also replace usage of PWD by
CURDIR. PWD is provided by most shells, but not all, so this makes the
build system more robust.Signed-off-by: Uwe Kleine-König
Signed-off-by: Michal Marek
03 Oct, 2016
2 commits
-
It is used in the build process, so stop suppressing its build in tools
cross builds.Signed-off-by: Jiri Olsa
Tested-by: Arnaldo Carvalho de Melo
Cc: Andi Kleen
Cc: Madhavan Srinivasan
Cc: Peter Zijlstra
Cc: Sukadev Bhattiprolu
Cc: linuxppc-dev@lists.ozlabs.org
Link: http://lkml.kernel.org/r/20160927141846.GA6589@krava
[ Use HOSTCC on the $(OUTPUT)fixdep target, it was using the x-compiler
to link fixdep-in.o, that was correctly built with HOSTCC and thus failing ]
Signed-off-by: Arnaldo Carvalho de Melo -
In some cases, like for fixdep and shortly for jevents, we need to build a tool
to run on the host that will be used in building a tool, such as perf, that is
being cross compiled, so do like the kernel and provide HOSTCC, HOSTLD and HOSTAR
to do that.Signed-off-by: Jiri Olsa
Requested-by: Andi Kleen
Requested-and-Tested-by: Arnaldo Carvalho de Melo
Cc: Madhavan Srinivasan
Cc: Peter Zijlstra
Cc: Sukadev Bhattiprolu
Cc: linuxppc-dev@lists.ozlabs.org
Link: http://lkml.kernel.org/r/20160927141846.GA6589@krava
Signed-off-by: Arnaldo Carvalho de Melo
27 Nov, 2015
1 commit
-
Adding OUTPUT path prefix for fixdep target so we use it properly in out
of tree builds.If the fixdep already existed in the tree, the out of tree build would
see it already exist and did not build the out of tree version, as
reported by Arnaldo:[acme@zoo linux]$ make O=/tmp/build/perf -C tools/perf
make: Entering directory '/home/git/linux/tools/perf'
BUILD: Doing 'make -j4' parallel build
make[2]: Nothing to be done for 'fixdep'.
make: Leaving directory '/home/git/linux/tools/perf'Reported-and-Tested-by: Arnaldo Carvalho de Melo
Signed-off-by: Jiri Olsa
Cc: David Ahern
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Wang Nan
Link: http://lkml.kernel.org/r/20151126185055.GC19410@krava.brq.redhat.com
[ Fixed conflict with 5725dd8fa888 ("tools build: Clean CFLAGS and LDFLAGS for fixdep") ]
Signed-off-by: Arnaldo Carvalho de Melo
29 Sep, 2015
1 commit
-
For dependency tracking we currently use targets that fall out of the
gcc -MD command. We store this info in the .cmd file and include as
makefile during the build.This format put object as target and all the c and header files as
dependencies, like:util/abspath.o: util/abspath.c /usr/include/stdc-predef.h util/cache.h \
/usr/include/bits/wordsize.h /usr/include/gnu/stubs.h \
...If any of those dependency header files (krava.h below) is removed the
build fails on:make[1]: *** No rule to make target 'krava.h', needed by 'inc.o'. Stop.
This patch adds fixdep helper, that is used by kbuild to alter the shape
of the object dependencies like:source_util/abspath.o := util/abspath.c
deps_util/abspath.o := \
/usr/include/stdc-predef.h \
util/cache.h \
...util/abspath.o: $(deps_util/abspath.o)
$(deps_util/abspath.o):
With this format the header removal won't make the build fail, because
it'll be picked up by the last empty target defined for each header.As previously mentioned the fixdep tool is taken from kbuild. It's not
complete backport, only the part that alters the standard dependency
info was taken, the part that adds the CONFIG_* dependency logic will be
probably taken later on.Signed-off-by: Jiri Olsa
Cc: David Ahern
Cc: Kai Germaschewski
Cc: Namhyung Kim
Cc: Peter Zijlstra
Link: http://lkml.kernel.org/r/1443004442-32660-4-git-send-email-jolsa@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo