@@ -25,6 +25,11 @@ lib-y := $(filter-out $(obj-y), $(sort $(lib-y) $(lib-m)))
# and -m subdirs. Just put -y's first.
modorder := $(patsubst %/,%/modules.order, $(filter %/, $(obj-y)) $(obj-m:.o=.ko))
+ifeq ($(KBUILD_EXTMOD),)
+# External modules may generate modules under subdir-y or subdir-m.
+modorder += $(addsuffix /modules.order, $(subdir-y) $(subdir-m))
+endif
+
# Handle objects in subdirs
# ---------------------------------------------------------------------------
# o if we encounter foo/ in $(obj-y), replace it by foo/built-in.a
Jan Kiszka reported a module build regression; since commit ff9b45c55b26 ("kbuild: modpost: read modules.order instead of $(MODVERDIR)/*.mod"), a module is no longer built in the following pattern: [Makefile] subdir-y := some-module [some-module/Makefile] obj-m := some-module.o You can make it work by writing like this: [Makefile] obj-m := some-module/ [some-module/Makefile] obj-m := some-module.o None of upstream Makefiles is written like the former. In fact, the former is a bug in upstream since modules.order is not correctly generated. For external modules, it was at least known to work, and being used by some people. This commit gets it back working, but I do not to want to encourage it for the upstream code, so I surrounded it by ifeq ($(KBUILD_EXTMOD),). Reported-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> --- I just wrote a fix-up patch, but I am still wondering if it is correct to build modules under subdir-y. scripts/Makefile.lib | 5 +++++ 1 file changed, 5 insertions(+) -- 2.17.1