From 4b21960f90d4d011e49e386d0525b1e89f320658 Mon Sep 17 00:00:00 2001 From: Trent Piepho Date: Thu, 11 Oct 2007 16:40:10 -0700 Subject: [PATCH] kbuild: modpost problem when symbols move from one module to another When part of build an external module tree, modpost first reads in the kernel's and then the external tree's Module.symvers files. From these files it establishes a symbol => module mapping. When it later reads in each module built and processes the symbols it finds, it discovers the symbol=>module mapping from Module.symvers and leaves it as it is. The problem comes with a module has been re-named or a symbol has moved from one module to another, since the Module.symvers file was generated. modpost does not update the symbol=>module mapping when it finds the new location of the symbol when scanning the newly built modules. This results in the module containing incorrect dependency information and the new Module.symvers file written by modpost will also contain the incorrect mappings, perpetuating the problem to the next build, and so on. When building the out of kernel development tree for kernel subsystem, like v4l-dvb or ALSA, deleting the external Module.symvers file before building (which the kernel build system doesn't do and shouldn't be necessary anyway), won't fix the problem. modpost still reads the kernel's Module.symvers, and since we a building a kernel subsystem, it will define the same symbols as the external modules. Signed-off-by: Trent Piepho Signed-off-by: Sam Ravnborg --- scripts/mod/modpost.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c index 2ef9a193fca..93ac52adb49 100644 --- a/scripts/mod/modpost.c +++ b/scripts/mod/modpost.c @@ -268,6 +268,9 @@ static struct symbol *sym_add_exported(const char *name, struct module *mod, "was in %s%s\n", mod->name, name, s->module->name, is_vmlinux(s->module->name) ?"":".ko"); + } else { + /* In case Modules.symvers was out of date */ + s->module = mod; } } s->preloaded = 0; -- 2.20.1