kbuild: modpost problem when symbols move from one module to another
authorTrent Piepho <xyzzy@speakeasy.org>
Thu, 11 Oct 2007 23:40:10 +0000 (16:40 -0700)
committerSam Ravnborg <sam@neptun.(none)>
Thu, 18 Oct 2007 11:35:49 +0000 (13:35 +0200)
commit4b21960f90d4d011e49e386d0525b1e89f320658
tree76ed26482c119857411fa589fc94a98fc877eb3c
parent37ab7a269637086d56940c31968f3fb3389b6d68
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 <xyzzy@speakeasy.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
scripts/mod/modpost.c