Some people want to do crazy things like pass multiple directories as the
value of $(SUBDIRS) or $M. Mostly this kinda works, except that
Makefile.modpost constructs a modpost commandline which fails modpost's
argument parsing. This patch fixes that little wrinkle.
Signed-off-by: Greg Banks <gnb@melbourne.sgi.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
On request from Al Viro make modpost processing configurable.
KBUILD_MODPOST_WARN can be set to make modpost warn instead of
error out in case on unresolved symbols in final module link.
KBUILD_MODPOST_NOFINAL can be set to avoid the final and timeconsuming
.c file generation and link of .ko files. This is solely useful for
speeding up when doing compile checks with for example allmodconfig
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
At stage 2 modpost utility is used to check modules. In case of unresolved
symbols modpost only prints warning.
IMHO it is a good idea to fail compilation process in case of unresolved
symbols (at least in modules coming with kernel), since usually such errors
are left unnoticed, but kernel modules are broken.
- new option '-w' is added to modpost:
if option is specified, modpost only warns about unresolved symbols
- modpost is called with '-w' for external modules in Makefile.modpost
Signed-off-by: Andrey Mirkin <amirkin@sw.ru>
Signed-off-by: Kirill Korotaev <dev@openvz.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Based on patch from: Magnus Damm <magnus@valinux.co.jp>
This has the advantage that all section mismatch checks are run regardless
of modules being enabled or not.
When running modpost on vmlinux output:
MODPOST vmlinux
When running modpost on modules output count of modules like this:
MODPOST 5 modules
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Reported by a Fedora user when they tried to build some out of tree module..
Signed-off-by: Dave Jones <davej@redhat.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
kbuild used $¤(*F to get filename of target without extension.
This was used in several places all over kbuild, but introducing
make -rR broke his for all cases where we specified full path to
target/prerequsite. It is assumed that make -rR disables old style
suffix-rules which is why is suddenly failed.
ia64 was impacted by this change because several div* routines in
arch/ia64/lib are build using explicit paths and then kbuild failed.
Thanks to David Mosberger-Tang <David.Mosberger@acm.org> for an explanation
what was the root-cause and for testing on ia64.
This patch also fixes two uses of $(*F) in arch/um
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
This reverts commit e5c44fd88c.
Thanks to Daniel Ritz and Michal Piotrowski for noticing the problem.
Daniel says:
"[The] reason is a recent change that made modules always shows as
module.mod. it breaks modprobe and probably many scripts..besides
lsmod looking horrible
stuff like this in modprobe.conf:
install pcmcia_core /sbin/modprobe --ignore-install pcmcia_core; /sbin/modprobe pcmcia
makes modprobe fork/exec endlessly calling itself...until oom
interrupts it"
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
make failed to supply the filename when using make -rR and using $(*F)
to get target filename without extension.
This bug was not reproduceable in small scale but using:
$(basename $(notdir $@)) fixes it with same functionality.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
This fixes one of the worst kbuild warts left - the broken dependencies used
to check and regenerate the .config file. This was done via an indirect
dependency and the .config itself had an empty command, which can cause make
not to reread the changed .config file.
Instead of this we generate now a new file include/config/auto.conf from
.config, which is used for kbuild and has the proper dependencies. It's also
the main make target now for all files generated during this step (and thus
replaces include/linux/autoconf.h).
This also means we can now relax the syntax requirements for the .config file
and we don't have to rewrite it all the time, i.e. silentoldconfig only
writes .config now when it's necessary to keep it in sync with the Kconfig
files and even this can be suppressed by setting the environment variable
KCONFIG_NOSILENTUPDATE, so the update can (and must) be done manually.
Signed-off-by: Roman Zippel <zippel@linux-m68k.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
The kbuild system takes advantage of an incorrect behavior in GNU make.
Once this behavior is fixed, all files in the kernel rebuild every time,
even if nothing has changed. This patch ensures kbuild works with both
the incorrect and correct behaviors of GNU make.
For more details on the incorrect behavior, see:
http://lists.gnu.org/archive/html/bug-make/2006-03/msg00003.html
Changes in this patch:
- Keep all targets that are to be marked .PHONY in a variable, PHONY.
- Add .PHONY: $(PHONY) to mark them properly.
- Remove any $(PHONY) files from the $? list when determining whether
targets are up-to-date or not.
Signed-off-by: Paul Smith <psmith@gnu.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
With following patch a second option is enabled to obtain
symbol information from a second external module when a
external module is build.
The recommended approach is to use a common kbuild file but
that may be impractical in certain cases.
With this patch one can copy over a Module.symvers from one
external module to make symbols (and symbol versions) available
for another external module.
Updated documentation in Documentation/kbuild/modules.txt
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Kbuild.include is a placeholder for definitions originally present in
both the top-level Makefile and scripts/Makefile.build.
There were a slight difference in the filechk definition, so the most videly
used version was kept and usr/Makefile was adopted for this syntax.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
---
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
Greg Banks