Searched +hist:5 +hist:f6e0fe0 (Results 1 - 3 of 3) sorted by relevance
/linux-master/scripts/ | ||
H A D | subarch.include | diff 5f6e0fe0 Wed Jun 09 20:03:31 MDT 2021 Masahiro Yamada <masahiroy@kernel.org> parisc: Fix compile failure when building 64-bit kernel natively Commit 23243c1ace9f ("arch: use cross_compiling to check whether it is a cross build or not") broke 64-bit parisc builds on 32-bit parisc systems. Helge mentioned: - 64-bit parisc userspace is not supported yet [1] - hppa gcc does not support "-m64" flag [2] That means, parisc developers working on a 32-bit parisc machine need to use hppa64-linux-gnu-gcc (cross compiler) for building the 64-bit parisc kernel. After the offending commit, gcc is used in such a case because both $(SRCARCH) and $(SUBARCH) are 'parisc', hence cross_compiling is unset. A correct way is to introduce ARCH=parisc64 because building the 64-bit parisc kernel on a 32-bit parisc system is not exactly a native build, but rather a semi-cross build. [1]: https://lore.kernel.org/linux-parisc/5dfd81eb-c8ca-b7f5-e80e-8632767c022d@gmx.de/#t [2]: https://lore.kernel.org/linux-parisc/89515325-fc21-31da-d238-6f7a9abbf9a0@gmx.de/ Fixes: 23243c1ace9f ("arch: use cross_compiling to check whether it is a cross build or not") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reported-by: Meelis Roos <mroos@linux.ee> Tested-by: Meelis Roos <mroos@linux.ee> Cc: <stable@vger.kernel.org> # v5.13+ Signed-off-by: Helge Deller <deller@gmx.de> diff 5f6e0fe0 Wed Jun 09 20:03:31 MDT 2021 Masahiro Yamada <masahiroy@kernel.org> parisc: Fix compile failure when building 64-bit kernel natively Commit 23243c1ace9f ("arch: use cross_compiling to check whether it is a cross build or not") broke 64-bit parisc builds on 32-bit parisc systems. Helge mentioned: - 64-bit parisc userspace is not supported yet [1] - hppa gcc does not support "-m64" flag [2] That means, parisc developers working on a 32-bit parisc machine need to use hppa64-linux-gnu-gcc (cross compiler) for building the 64-bit parisc kernel. After the offending commit, gcc is used in such a case because both $(SRCARCH) and $(SUBARCH) are 'parisc', hence cross_compiling is unset. A correct way is to introduce ARCH=parisc64 because building the 64-bit parisc kernel on a 32-bit parisc system is not exactly a native build, but rather a semi-cross build. [1]: https://lore.kernel.org/linux-parisc/5dfd81eb-c8ca-b7f5-e80e-8632767c022d@gmx.de/#t [2]: https://lore.kernel.org/linux-parisc/89515325-fc21-31da-d238-6f7a9abbf9a0@gmx.de/ Fixes: 23243c1ace9f ("arch: use cross_compiling to check whether it is a cross build or not") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reported-by: Meelis Roos <mroos@linux.ee> Tested-by: Meelis Roos <mroos@linux.ee> Cc: <stable@vger.kernel.org> # v5.13+ Signed-off-by: Helge Deller <deller@gmx.de> diff 5f6e0fe0 Wed Jun 09 20:03:31 MDT 2021 Masahiro Yamada <masahiroy@kernel.org> parisc: Fix compile failure when building 64-bit kernel natively Commit 23243c1ace9f ("arch: use cross_compiling to check whether it is a cross build or not") broke 64-bit parisc builds on 32-bit parisc systems. Helge mentioned: - 64-bit parisc userspace is not supported yet [1] - hppa gcc does not support "-m64" flag [2] That means, parisc developers working on a 32-bit parisc machine need to use hppa64-linux-gnu-gcc (cross compiler) for building the 64-bit parisc kernel. After the offending commit, gcc is used in such a case because both $(SRCARCH) and $(SUBARCH) are 'parisc', hence cross_compiling is unset. A correct way is to introduce ARCH=parisc64 because building the 64-bit parisc kernel on a 32-bit parisc system is not exactly a native build, but rather a semi-cross build. [1]: https://lore.kernel.org/linux-parisc/5dfd81eb-c8ca-b7f5-e80e-8632767c022d@gmx.de/#t [2]: https://lore.kernel.org/linux-parisc/89515325-fc21-31da-d238-6f7a9abbf9a0@gmx.de/ Fixes: 23243c1ace9f ("arch: use cross_compiling to check whether it is a cross build or not") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reported-by: Meelis Roos <mroos@linux.ee> Tested-by: Meelis Roos <mroos@linux.ee> Cc: <stable@vger.kernel.org> # v5.13+ Signed-off-by: Helge Deller <deller@gmx.de> |
/linux-master/arch/parisc/ | ||
H A D | Makefile | diff 5f6e0fe0 Wed Jun 09 20:03:31 MDT 2021 Masahiro Yamada <masahiroy@kernel.org> parisc: Fix compile failure when building 64-bit kernel natively Commit 23243c1ace9f ("arch: use cross_compiling to check whether it is a cross build or not") broke 64-bit parisc builds on 32-bit parisc systems. Helge mentioned: - 64-bit parisc userspace is not supported yet [1] - hppa gcc does not support "-m64" flag [2] That means, parisc developers working on a 32-bit parisc machine need to use hppa64-linux-gnu-gcc (cross compiler) for building the 64-bit parisc kernel. After the offending commit, gcc is used in such a case because both $(SRCARCH) and $(SUBARCH) are 'parisc', hence cross_compiling is unset. A correct way is to introduce ARCH=parisc64 because building the 64-bit parisc kernel on a 32-bit parisc system is not exactly a native build, but rather a semi-cross build. [1]: https://lore.kernel.org/linux-parisc/5dfd81eb-c8ca-b7f5-e80e-8632767c022d@gmx.de/#t [2]: https://lore.kernel.org/linux-parisc/89515325-fc21-31da-d238-6f7a9abbf9a0@gmx.de/ Fixes: 23243c1ace9f ("arch: use cross_compiling to check whether it is a cross build or not") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reported-by: Meelis Roos <mroos@linux.ee> Tested-by: Meelis Roos <mroos@linux.ee> Cc: <stable@vger.kernel.org> # v5.13+ Signed-off-by: Helge Deller <deller@gmx.de> diff 5f6e0fe0 Wed Jun 09 20:03:31 MDT 2021 Masahiro Yamada <masahiroy@kernel.org> parisc: Fix compile failure when building 64-bit kernel natively Commit 23243c1ace9f ("arch: use cross_compiling to check whether it is a cross build or not") broke 64-bit parisc builds on 32-bit parisc systems. Helge mentioned: - 64-bit parisc userspace is not supported yet [1] - hppa gcc does not support "-m64" flag [2] That means, parisc developers working on a 32-bit parisc machine need to use hppa64-linux-gnu-gcc (cross compiler) for building the 64-bit parisc kernel. After the offending commit, gcc is used in such a case because both $(SRCARCH) and $(SUBARCH) are 'parisc', hence cross_compiling is unset. A correct way is to introduce ARCH=parisc64 because building the 64-bit parisc kernel on a 32-bit parisc system is not exactly a native build, but rather a semi-cross build. [1]: https://lore.kernel.org/linux-parisc/5dfd81eb-c8ca-b7f5-e80e-8632767c022d@gmx.de/#t [2]: https://lore.kernel.org/linux-parisc/89515325-fc21-31da-d238-6f7a9abbf9a0@gmx.de/ Fixes: 23243c1ace9f ("arch: use cross_compiling to check whether it is a cross build or not") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reported-by: Meelis Roos <mroos@linux.ee> Tested-by: Meelis Roos <mroos@linux.ee> Cc: <stable@vger.kernel.org> # v5.13+ Signed-off-by: Helge Deller <deller@gmx.de> diff 5f6e0fe0 Wed Jun 09 20:03:31 MDT 2021 Masahiro Yamada <masahiroy@kernel.org> parisc: Fix compile failure when building 64-bit kernel natively Commit 23243c1ace9f ("arch: use cross_compiling to check whether it is a cross build or not") broke 64-bit parisc builds on 32-bit parisc systems. Helge mentioned: - 64-bit parisc userspace is not supported yet [1] - hppa gcc does not support "-m64" flag [2] That means, parisc developers working on a 32-bit parisc machine need to use hppa64-linux-gnu-gcc (cross compiler) for building the 64-bit parisc kernel. After the offending commit, gcc is used in such a case because both $(SRCARCH) and $(SUBARCH) are 'parisc', hence cross_compiling is unset. A correct way is to introduce ARCH=parisc64 because building the 64-bit parisc kernel on a 32-bit parisc system is not exactly a native build, but rather a semi-cross build. [1]: https://lore.kernel.org/linux-parisc/5dfd81eb-c8ca-b7f5-e80e-8632767c022d@gmx.de/#t [2]: https://lore.kernel.org/linux-parisc/89515325-fc21-31da-d238-6f7a9abbf9a0@gmx.de/ Fixes: 23243c1ace9f ("arch: use cross_compiling to check whether it is a cross build or not") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reported-by: Meelis Roos <mroos@linux.ee> Tested-by: Meelis Roos <mroos@linux.ee> Cc: <stable@vger.kernel.org> # v5.13+ Signed-off-by: Helge Deller <deller@gmx.de> diff 4c01acc0 Mon Jun 04 22:54:09 MDT 2012 James Bottomley <JBottomley@Parallels.com> [PARISC] fix code to find libgcc Sam broke this with commit 1f2bfbd00e466ff3489b2ca5cc75b1cccd14c123 Author: Sam Ravnborg <sam@ravnborg.org> Date: Sat May 5 10:18:41 2012 +0200 kbuild: link of vmlinux moved to a script But we should be deriving the location of libgcc in the same way as all the other archs, so fix by adding a LIBGCC variable which is evaluated in the makefile Signed-off-by: James Bottomley <JBottomley@Parallels.com> diff 5feb4f39 Thu Oct 18 16:09:59 MDT 2007 Kyle McMartin <kyle@shortfin.cabal.ca> [PARISC] Restore palo target Turns out, people were still using it, and it accidently works. Signed-off-by: Kyle McMartin <kyle@mcmartin.ca> diff 5beb5f32 Fri Oct 21 20:52:00 MDT 2005 Randolph Chung <tausq@parisc-linux.org> [PARISC] Update minimum compiler version and CROSS_COMPILE for parisc64 Prefix changed in debian, include "gnu" in the commandline. Signed-off-by: Carlos O'Donell <carlos@parisc-linux.org> Ensure the compiler version is new enough (>= 3.3) Signed-off-by: Randolph Chung <tausq@parisc-linux.org> Signed-off-by: Kyle McMartin <kyle@parisc-linux.org> |
/linux-master/ | ||
H A D | Makefile | diff e2bad142 Wed Mar 06 03:42:22 MST 2024 Masahiro Yamada <masahiroy@kernel.org> kbuild: unexport abs_srctree and abs_objtree Commit 25b146c5b8ce ("kbuild: allow Kbuild to start from any directory") exported abs_srctree and abs_objtree to avoid recomputation after the sub-make. However, this approach turned out to be fragile. Commit 5fa94ceb793e ("kbuild: set correct abs_srctree and abs_objtree for package builds") moved them above "ifneq ($(sub_make_done),1)", eliminating the need for exporting them. These are only needed in the top Makefile. If an absolute path is required in sub-directories, you can use $(abspath ) or $(realpath ) as needed. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu> diff 5e02797b Wed Aug 23 05:50:46 MDT 2023 Masahiro Yamada <masahiroy@kernel.org> kbuild: move more module installation code to scripts/Makefile.modinst Move more relevant code to scripts/Makefile.modinst. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu> diff 1fdd7290 Sat Aug 19 05:43:01 MDT 2023 Masahiro Yamada <masahiroy@kernel.org> kbuild: remove include/ksym from CLEAN_FILES This is a remnant of commit 5e9e95cc9148 ("kbuild: implement CONFIG_TRIM_UNUSED_KSYMS without recursion"). Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> diff 5d0c230f Sun Jul 30 14:23:47 MDT 2023 Linus Torvalds <torvalds@linux-foundation.org> Linux 6.5-rc4 diff 5fc10e76 Mon Jun 26 17:30:13 MDT 2023 Masahiro Yamada <masahiroy@kernel.org> kbuild: revive "Entering directory" for Make >= 4.4.1 With commit 9da0763bdd82 ("kbuild: Use relative path when building in a subdir of the source tree"), compiler messages in out-of-tree builds include relative paths, which are relative to the build directory, not the directory where make was started. To help IDEs/editors find the source files, Kbuild lets GNU Make print "Entering directory ..." when it changes the working directory. It has been working fine for a long time, but David reported it is broken with the latest GNU Make. The behavior was changed by GNU Make commit 8f9e7722ff0f ("[SV 63537] Fix setting -w in makefiles"). Previously, setting --no-print-directory to MAKEFLAGS only affected child makes, but it is now interpreted in the current make as soon as it is set. [test code] $ cat /tmp/Makefile ifneq ($(SUBMAKE),1) MAKEFLAGS += --no-print-directory all: ; $(MAKE) SUBMAKE=1 else all: ; : endif [before 8f9e7722ff0f] $ make -C /tmp make: Entering directory '/tmp' make SUBMAKE=1 : make: Leaving directory '/tmp' [after 8f9e7722ff0f] $ make -C /tmp make SUBMAKE=1 : Previously, the effect of --no-print-directory was delayed until Kbuild started the directory descending, but it is no longer true with GNU Make 4.4.1. This commit adds one more recursion to cater to GNU Make >= 4.4.1. When Kbuild needs to change the working directory, __submake will be executed twice. __submake without --no-print-directory --> show "Entering directory ..." __submake with --no-print-directory --> parse the rest of Makefile We end up with one more recursion than needed for GNU Make < 4.4.1, but I do not want to complicate the version check. Reported-by: David Howells <dhowells@redhat.com> Closes: https://lore.kernel.org/all/2427604.1686237298@warthog.procyon.org.uk/ Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Tested-by: Nicolas Schier <n.schier@avm.de> diff 5fa94ceb Mon Jun 26 17:30:12 MDT 2023 Masahiro Yamada <masahiroy@kernel.org> kbuild: set correct abs_srctree and abs_objtree for package builds When you run 'make rpm-pkg', the rpmbuild tool builds the kernel in rpmbuild/BUILD, but $(abs_srctree) and $(abs_objtree) point to the directory path where make was started, not the kernel is actually being built. The same applies to 'make snap-pkg'. Fix it. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> diff 5e9e95cc9 Sun Jun 11 09:50:57 MDT 2023 Masahiro Yamada <masahiroy@kernel.org> kbuild: implement CONFIG_TRIM_UNUSED_KSYMS without recursion When CONFIG_TRIM_UNUSED_KSYMS is enabled, Kbuild recursively traverses the directory tree to determine which EXPORT_SYMBOL to trim. If an EXPORT_SYMBOL turns out to be unused by anyone, Kbuild begins the second traverse, where some source files are recompiled with their EXPORT_SYMBOL() tuned into a no-op. Linus stated negative opinions about this slowness in commits: - 5cf0fd591f2e ("Kbuild: disable TRIM_UNUSED_KSYMS option") - a555bdd0c58c ("Kbuild: enable TRIM_UNUSED_KSYMS again, with some guarding") We can do this better now. The final data structures of EXPORT_SYMBOL are generated by the modpost stage, so modpost can selectively emit KSYMTAB entries that are really used by modules. Commit f73edc8951b2 ("kbuild: unify two modpost invocations") is another ground-work to do this in a one-pass algorithm. With the list of modules, modpost sets sym->used if it is used by a module. modpost emits KSYMTAB only for symbols with sym->used==true. BTW, Nicolas explained why the trimming was implemented with recursion: https://lore.kernel.org/all/2o2rpn97-79nq-p7s2-nq5-8p83391473r@syhkavp.arg/ Actually, we never achieved that level of optimization where the chain reaction of trimming comes into play because: - CONFIG_LTO_CLANG cannot remove any unused symbols - CONFIG_LD_DEAD_CODE_DATA_ELIMINATION is enabled only for vmlinux, but not modules If deeper trimming is required, we need to revisit this, but I guess that is unlikely to happen. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> diff 5e9e95cc9 Sun Jun 11 09:50:57 MDT 2023 Masahiro Yamada <masahiroy@kernel.org> kbuild: implement CONFIG_TRIM_UNUSED_KSYMS without recursion When CONFIG_TRIM_UNUSED_KSYMS is enabled, Kbuild recursively traverses the directory tree to determine which EXPORT_SYMBOL to trim. If an EXPORT_SYMBOL turns out to be unused by anyone, Kbuild begins the second traverse, where some source files are recompiled with their EXPORT_SYMBOL() tuned into a no-op. Linus stated negative opinions about this slowness in commits: - 5cf0fd591f2e ("Kbuild: disable TRIM_UNUSED_KSYMS option") - a555bdd0c58c ("Kbuild: enable TRIM_UNUSED_KSYMS again, with some guarding") We can do this better now. The final data structures of EXPORT_SYMBOL are generated by the modpost stage, so modpost can selectively emit KSYMTAB entries that are really used by modules. Commit f73edc8951b2 ("kbuild: unify two modpost invocations") is another ground-work to do this in a one-pass algorithm. With the list of modules, modpost sets sym->used if it is used by a module. modpost emits KSYMTAB only for symbols with sym->used==true. BTW, Nicolas explained why the trimming was implemented with recursion: https://lore.kernel.org/all/2o2rpn97-79nq-p7s2-nq5-8p83391473r@syhkavp.arg/ Actually, we never achieved that level of optimization where the chain reaction of trimming comes into play because: - CONFIG_LTO_CLANG cannot remove any unused symbols - CONFIG_LD_DEAD_CODE_DATA_ELIMINATION is enabled only for vmlinux, but not modules If deeper trimming is required, we need to revisit this, but I guess that is unlikely to happen. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> diff 05e96e96 Wed Mar 15 09:50:18 MDT 2023 Masahiro Yamada <masahiroy@kernel.org> kbuild: use git-archive for source package creation Commit 5c3d1d0abb12 ("kbuild: add a tool to list files ignored by git") added a new tool, scripts/list-gitignored. My intention was to create source packages without cleaning the source tree, without relying on git. Linus strongly objected to it, and suggested using 'git archive' instead. [1] [2] [3] This commit goes in that direction - Remove scripts/list-gitignored.c and rewrites Makefiles and scripts to use 'git archive' for building Debian and RPM source packages. It also makes 'make perf-tar*-src-pkg' use 'git archive' again. Going forward, building source packages is only possible in a git-managed tree. Building binary packages does not require git. [1]: https://lore.kernel.org/lkml/CAHk-=wi49sMaC7vY1yMagk7eqLK=1jHeHQ=yZ_k45P=xBccnmA@mail.gmail.com/ [2]: https://lore.kernel.org/lkml/CAHk-=wh5AixGsLeT0qH2oZHKq0FLUTbyTw4qY921L=PwYgoGVw@mail.gmail.com/ [3]: https://lore.kernel.org/lkml/CAHk-=wgM-W6Fu==EoAVCabxyX8eYBz9kNC88-tm9ExRQwA79UQ@mail.gmail.com/ Fixes: 5c3d1d0abb12 ("kbuild: add a tool to list files ignored by git") Fixes: e0ca16749ac3 ("kbuild: make perf-tar*-src-pkg work without relying on git") Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> diff 05e96e96 Wed Mar 15 09:50:18 MDT 2023 Masahiro Yamada <masahiroy@kernel.org> kbuild: use git-archive for source package creation Commit 5c3d1d0abb12 ("kbuild: add a tool to list files ignored by git") added a new tool, scripts/list-gitignored. My intention was to create source packages without cleaning the source tree, without relying on git. Linus strongly objected to it, and suggested using 'git archive' instead. [1] [2] [3] This commit goes in that direction - Remove scripts/list-gitignored.c and rewrites Makefiles and scripts to use 'git archive' for building Debian and RPM source packages. It also makes 'make perf-tar*-src-pkg' use 'git archive' again. Going forward, building source packages is only possible in a git-managed tree. Building binary packages does not require git. [1]: https://lore.kernel.org/lkml/CAHk-=wi49sMaC7vY1yMagk7eqLK=1jHeHQ=yZ_k45P=xBccnmA@mail.gmail.com/ [2]: https://lore.kernel.org/lkml/CAHk-=wh5AixGsLeT0qH2oZHKq0FLUTbyTw4qY921L=PwYgoGVw@mail.gmail.com/ [3]: https://lore.kernel.org/lkml/CAHk-=wgM-W6Fu==EoAVCabxyX8eYBz9kNC88-tm9ExRQwA79UQ@mail.gmail.com/ Fixes: 5c3d1d0abb12 ("kbuild: add a tool to list files ignored by git") Fixes: e0ca16749ac3 ("kbuild: make perf-tar*-src-pkg work without relying on git") Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> |
Completed in 1091 milliseconds