BMC/Intel-BMC/linux.git/Makefile, branch v5.0.11

Linux 5.0.11

2019-05-02T08:02:58+00:00

Linux 5.0.10

2019-04-27T07:37:45+00:00

Revert "kbuild: use -Oz instead of -Os when using clang"

2019-04-27T07:37:44+00:00

commit a75bb4eb9e565b9f5115e2e8c07377ce32cbe69a upstream. The clang option -Oz enables *aggressive* optimization for size, which doesn't necessarily result in smaller images, but can have negative impact on performance. Switch back to the less aggressive -Os. This reverts commit 6748cb3c299de1ffbe56733647b01dbcc398c419. Suggested-by: Peter Zijlstra Signed-off-by: Matthias Kaehlcke Reviewed-by: Nick Desaulniers Signed-off-by: Masahiro Yamada Signed-off-by: Nathan Chancellor Signed-off-by: Sasha Levin

Linux 5.0.9

2019-04-20T07:17:05+00:00

Linux 5.0.8

2019-04-17T06:39:54+00:00

kbuild: clang: choose GCC_TOOLCHAIN_DIR not on LD

2019-04-17T06:39:44+00:00

[ Upstream commit ad15006cc78459d059af56729c4d9bed7c7fd860 ] This causes an issue when trying to build with `make LD=ld.lld` if ld.lld and the rest of your cross tools aren't in the same directory (ex. /usr/local/bin) (as is the case for Android's build system), as the GCC_TOOLCHAIN_DIR then gets set based on `which $(LD)` which will point where LLVM tools are, not GCC/binutils tools are located. Instead, select the GCC_TOOLCHAIN_DIR based on another tool provided by binutils for which LLVM does not provide a substitute for, such as elfedit. Fixes: 785f11aa595b ("kbuild: Add better clang cross build support") Link: https://github.com/ClangBuiltLinux/linux/issues/341 Suggested-by: Nathan Chancellor Reviewed-by: Nathan Chancellor Tested-by: Nathan Chancellor Signed-off-by: Nick Desaulniers Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin

Linux 5.0.7

2019-04-05T20:34:54+00:00

kbuild: skip sub-make for in-tree build with GNU Make 4.x

2019-04-05T20:34:54+00:00

commit 688931a5ad4e55ba0c215248ba510cd67bc3afb4 upstream. Commit 2b50f7ab6368 ("kbuild: add workaround for Debian make-kpkg") annoyed people who want to wrap the top Makefile with GNUmakefile to customize it for their use. On second thought, we do not need to run the sub-make for in-tree build with Make 4.x because the 'MAKEFLAGS += -rR' issue only happens on GNU Make 3.x. With this commit, people will get back their workflow, and the Debian make-kpkg will still work. Fixes: 2b50f7ab6368 ("kbuild: add workaround for Debian make-kpkg") Reported-by: Andreas Schwab Reported-by: David Howells Signed-off-by: Masahiro Yamada Tested-by: Andreas Schwab Tested-by: David Howells Signed-off-by: Greg Kroah-Hartman

kbuild: add workaround for Debian make-kpkg

2019-04-05T20:34:54+00:00

commit 2b50f7ab63685cd247e32ad321f7338ed130d3d5 upstream. Since commit 3812b8c5c5d5 ("kbuild: make -r/-R effective in top Makefile for old Make versions"), make-kpkg is not working. make-kpkg directly includes the top Makefile of Linux kernel, and appends some debian_* targets. /usr/share/kernel-package/ruleset/kernel_version.mk: # Include the kernel makefile override dot-config := 1 include Makefile dot-config := 1 I did not know the kernel Makefile was used in that way, and it is hard to guarantee the behavior when the kernel Makefile is included by another Makefile from a different project. It looks like Debian Stretch stopped providing make-kpkg. Maybe it is obsolete and being replaced with 'make deb-pkg' etc. but still widely used. This commit adds a workaround; if the top Makefile is included by another Makefile, skip sub-make in order to make the main part visible. 'MAKEFLAGS += -rR' does not become effective for GNU Make < 4.0, but Debian/Ubuntu is already using newer versions. The effect of this commit: Debian 8 (Jessie) : Fixed Debian 9 (Stretch) : make-kpkg (kernel-package) is not provided Ubuntu 14.04 LTS : NOT Fixed Ubuntu 16.04 LTS : Fixed Ubuntu 18.04 LTS : Fixed This commit cannot fix Ubuntu 14.04 because it installs GNU Make 3.81, but its support will end in Apr 2019, which is before the Linux v5.1 release. I added warning so that nobody would try to include the top Makefile. Fixes: 3812b8c5c5d5 ("kbuild: make -r/-R effective in top Makefile for old Make versions") Reported-by: Liz Zhang Signed-off-by: Masahiro Yamada Tested-by: Lili Deng Cc: Manoj Srivastava Signed-off-by: Greg Kroah-Hartman

kbuild: make -r/-R effective in top Makefile for old Make versions

2019-04-05T20:34:28+00:00

[ Upstream commit 3812b8c5c5d527239ac015f1f2c7654da7fcfbba ] Adding -rR to MAKEFLAGS is important because we do not want to be bothered by built-in implicit rules or variables. One problem that used to exist in older GNU Make versions is MAKEFLAGS += -rR ... does not become effective in the current Makefile. When you are building with O= option, it becomes effective in the top Makefile since it recurses via 'sub-make' target. Otherwise, the top Makefile tries implicit rules. That is why we explicitly add empty rules for Makefiles, but we often miss to do that. In fact, adding -d option to older GNU Make versions shows it is trying a bunch of implicit pattern rules. Considering target file `scripts/Makefile.kcov'. Looking for an implicit rule for `scripts/Makefile.kcov'. Trying pattern rule with stem `Makefile.kcov'. Trying implicit prerequisite `scripts/Makefile.kcov.o'. Trying pattern rule with stem `Makefile.kcov'. Trying implicit prerequisite `scripts/Makefile.kcov.c'. Trying pattern rule with stem `Makefile.kcov'. Trying implicit prerequisite `scripts/Makefile.kcov.cc'. Trying pattern rule with stem `Makefile.kcov'. Trying implicit prerequisite `scripts/Makefile.kcov.C'. ... This issue was fixed by GNU Make commit 58dae243526b ("[Savannah #20501] Handle adding -r/-R to MAKEFLAGS in the makefile"). So, it is no longer a problem if you use GNU Make 4.0 or later. However, older versions are still widely used. So, I decided to patch the kernel Makefile to invoke sub-make regardless of O= option. This will allow further cleanups. Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin