linux/Makefile, branch v4.19

Linux 4.19

2018-10-22T06:37:37Z

Linux 4.19-rc8

2018-10-15T05:20:24Z

Merge tag 'kbuild-fixes-v4.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild

2018-10-11T17:23:07Z

Masahiro writes: "Kbuild fixes for v4.19 (2nd) - Fix warnings from recordmcount.pl when building with Clang - Allow Clang to use GNU toolchains correctly - Disable CONFIG_SAMPLES for UML to avoid build error" * tag 'kbuild-fixes-v4.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: samples: disable CONFIG_SAMPLES for UML kbuild: allow to use GCC toolchain not in Clang search path ftrace: Build with CPPFLAGS to get -Qunused-arguments

Linux 4.19-rc7

2018-10-07T15:26:02Z

Linux 4.19-rc6

2018-09-30T14:15:35Z

Linux 4.19-rc5

2018-09-23T17:15:18Z

kbuild: allow to use GCC toolchain not in Clang search path

2018-09-19T14:55:45Z

When using a GCC cross toolchain which is not in a compiled in Clang search path, Clang reverts to the system assembler and linker. This leads to assembler or linker errors, depending on which tool is first used for a given architecture. It seems that Clang is not searching $PATH for a matching assembler or linker. Make sure that Clang picks up the correct assembler or linker by passing the cross compilers bin directory as search path. This allows to use Clang provided by distributions with GCC toolchains not in /usr/bin. Link: https://github.com/ClangBuiltLinux/linux/issues/78 Signed-off-by: Stefan Agner Reviewed-and-tested-by: Nick Desaulniers Signed-off-by: Masahiro Yamada

Merge tag 'linux-kselftest-4.19-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest

2018-09-17T05:24:28Z

Pulled kselftest fixes from Shuah: "This Kselftest fixes update for 4.9-rc5 consists of: -- fixes to build failures -- fixes to add missing config files to increase test coverage -- fixes to cgroup test and a new cgroup test for memory.oom.group"

Linux 4.19-rc4

2018-09-16T18:52:37Z

tracing/Makefile: Fix handling redefinition of CC_FLAGS_FTRACE

2018-09-12T18:32:18Z

As a Kernel developer, I make heavy use of "make targz-pkg" in order to locally compile and remotely install my development Kernels. The nice feature I rely on is that after a normal "make", "make targz-pkg" only generates the tarball without having to recompile everything. That was true until commit f28bc3c32c05 ("tracing: Handle CC_FLAGS_FTRACE more accurately"). After it, running "make targz-pkg" after "make" will recompile the whole Kernel tree, making my development workflow much slower. The Kernel is choosing to recompile everything because it claims the command line has changed. A diff of the .cmd files show a repeated -mfentry in one of the files. That is because "make targz-pkg" calls "make modules_install" and the environment is already populated with the exported variables, CC_FLAGS_FTRACE being one of them. Then, -mfentry gets duplicated because it is not protected behind an ifndef block, like -pg. To complicate the problem a little bit more, architectures can define their own version CC_FLAGS_FTRACE, so our code not only has to consider recursive Makefiles, but also architecture overrides. So in this patch we move CC_FLAGS_FTRACE up and unconditionally define it to -pg. Then we let the architecture Makefiles possibly override it, and finally append the extra options later. This ensures the variable is always fully redefined at each invocation so recursive Makefiles don't keep appending, and hopefully it maintains the intended behavior on how architectures can override the defaults.. Thanks Steven Rostedt and Vasily Gorbik for the help on this regression. Cc: Michal Marek Cc: Ingo Molnar Cc: Tvrtko Ursulin Cc: linux-kbuild@vger.kernel.org Fixes: commit f28bc3c32c05 ("tracing: Handle CC_FLAGS_FTRACE more accurately") Acked-by: Vasily Gorbik Signed-off-by: Paulo Zanoni Signed-off-by: Steven Rostedt (VMware)