Bug 7042
Summary: | Recursing into /lib/modules/`uname -r`/build infects my build environment | ||
---|---|---|---|
Product: | Other | Reporter: | Tristan Van Berkom (tristan.van.berkom) |
Component: | Modules | Assignee: | Sam Ravnborg (sam) |
Status: | REJECTED WILL_NOT_FIX | ||
Severity: | normal | CC: | bunk, francois.guy, protasnb |
Priority: | P2 | ||
Hardware: | i386 | ||
OS: | Linux | ||
Kernel Version: | 2.6.17.7 | Subsystem: | |
Regression: | --- | Bisected commit-id: | |
Attachments: |
output of "make -d"
workaround patch |
Description
Tristan Van Berkom
2006-08-22 14:33:27 UTC
Thanks for the report. I will try to reproduce it locally. Can you try to attach the outut of the build with the flag: V=1 added to the make commnad line - this enables some more verbose output from kbuild. Unfortunately V=1 gives me no additional output (although that in itself may be meaningfull to you) - I guess since GNU make evaluates its own makefiles as targets before considering any other targets. I could attach the output of "make -d" if you want... Created attachment 8897 [details]
output of "make -d"
I found something interesting, from examining the make debugging output
generated with make -d, it looks like the kernel makefiles are using a VPATH
that is finding a prerequisite in _my_ build environment (from which it was
recursed into).
So, If I check-out my build tree, and then unpack the kernel build tree,
I have no problems since the kernel makefiles are _newer_ than the makefiles
found in _my_ SCCS directories.
If I go on to modify and commit my own makefiles locally, it starts breaking
because the kernel wants to update _its own makefiles_ based on the fact that
my SCCS/s.Makefile is newer.
While the problem is clear to me now - and could be fixed by avoiding vpath
evil in kernel makefiles, I do not propose that it be fixed - the way a program
compiles itself with its own makefiles is entirely its own bussiness. A proper
fix would be to provide some proper compiler flags to the module builder so
that the module builder can build on its own.
Created attachment 8898 [details]
workaround patch
I am currently reverting this line in the toplevel kernel makefile
to workaround the problem, it seems to be working ok.
Any update on this problem? Thanks. The bug is thus: By way of the VPATH line in the master kernel makefile, the makefile is saying that my personal kernel module's directory should be taken into account as "One of the kernel directories". This assumption is obviously false, I have my own revisioned files in my own build sandbox and my own rules which apply to update files in that sandbox. What should happen ? : - The kernel makefiles should have a clean rule that will invoke make in my directory without inheriting all the rules of the kernel make mechanism (just .ko:.o, .o:.c) or even better: - The kernel should simply have a pkg-config like program or even textfile to let module authors know what are the correct compile flags and include paths to compile a module with. What is the status of this problem? has it been resolved? thanks. I dont work for the same company anymore and dont have the setup to test the latest build. If you are still using the VPATH variable in the makefile, and expecting your build to work in someone else's module directory, then I expect it to still be a bug yes. In the end, you cant really publish your build system and expect it to work in someone elses environment, it will have different bugs for people who have different environments. You also cant really expect people to archive the compiled .ko files in their build systems (i.e. imagine that to rebuild to kernel module for a given build tree, you had to check out the kernel source and build it by hand and commit the .ko file just to satisfy the dependancy... it just doesnt work that way). Documenting the kernel flags is also out of the question (i.e. in the older days you just had to read the docs and put -DMODULE etc on your build line... since these days the required build flags may change alot, its just a nightmare to maintain these kinds of docs). So in the end the only real solution would be for the kernel to output a kernel module .pc file, even if it had to output a different one for different driver subsystems and directory levels - nobody would have to explicitly know or transmit the compile flags, and they would always be available for a given kernel dist. Hi Tristan. > If you are still using the VPATH variable in the makefile, and > expecting your build to work in someone else's module directory, > then I expect it to still be a bug yes. kbuild continue to use VPATH and it works well in almost all cases. In this particular case it seems that kernel module source where mixed with some other source file otherwise the mentioned bug should not trigger. > You also cant really expect people to archive the compiled .ko > files in their build systems (i.e. imagine that to rebuild to > kernel module for a given build tree, you had to check out the > kernel source and build it by hand and commit the .ko file > just to satisfy the dependancy... it just doesnt work that way). The build system will build the .ko file if told so and it is missin or any prerequisite has changed - like anyone would expect. So to build a module you will need the prepared kernel source (tools built etc). That is the only supported way to build kernel modules. So unless you convince me otherwise I do not consider this a bug. Sam (In reply to comment #9) > Hi Tristan. > > > If you are still using the VPATH variable in the makefile, and > > expecting your build to work in someone else's module directory, > > then I expect it to still be a bug yes. > kbuild continue to use VPATH and it works well in almost all cases. > In this particular case it seems that kernel module source where > mixed with some other source file otherwise the mentioned bug > should not trigger. > > > You also cant really expect people to archive the compiled .ko > > files in their build systems (i.e. imagine that to rebuild to > > kernel module for a given build tree, you had to check out the > > kernel source and build it by hand and commit the .ko file > > just to satisfy the dependancy... it just doesnt work that way). > The build system will build the .ko file if told so and it is > missin or any prerequisite has changed - like anyone would > expect. So to build a module you will need the prepared > kernel source (tools built etc). > That is the only supported way to build kernel modules. > > So unless you convince me otherwise I do not consider this a bug. Generally you do not distribute build systems, sure this is fine for any kernel module that is included and built inside the kernel tree, those must be integrated in the kernel build tree anyway. But the reality is that people need to build their own modules that link in the kernel, and these people will want to build thier kernel modules in an automated way in their own build systems. As much as you are not convinced that building kernel modules outside of the kernel tree is a requirement - I dont see any convincing reason for the kernel to be an exception to the standard: to build modules, libraries and objects, you need a set of compiler flags to be provided, and binaries possibly to be linked against. Imagine firefox made you use their own makefiles and build firefox every time you wanted to use the embedding api - currently this is almost the case but at least they are working on a proper sdk (now I believe its the xulrunner dist if you manage to compile it). At any rate, if you insist that distributing a build environment is an acceptable way to provide compilation support to module/driver developers, then this one does have bugs - because in this particular case the kernel makefiles are making assumptions about irrelevent files that are found in my own build directory (IMO use of VPATH is the culprit in this case - using exact file lists based on variables passed to the kernel makefiles, at least for externally built modules would avoid these assumptions). Just because what you guys are doing is different from everybody else doesnt mean I can say its wrong, but Im sure alot of build headaches for everyone involved could be saved by biting the bullet and just dumping the proper compile flags into a generated file that may differ between kernel builds and systems - Im sure it would be easier for you to maintain than trying to maintain these distributed makefiles. -Tristan Hi Tristan. It has been discussed to provide a external-module-sdk which would be a subset of the relevant files from the kernel. But there has not been any push for it and noone has come up with a patch either - so for now this is not supported. > But the reality is that people need to build their own modules > that link in the kernel, and these people will want to build thier > kernel modules in an automated way in their own build systems. Use: cd dir_with_module; make -C KERNEL_DIR M=`pwd` and if any prerequisites are outdated - your module will be build. > As much as you are not convinced that building kernel modules > outside of the kernel tree is a requirement - I dont see any convincing > reason for the kernel to be an exception to the standard: to > build modules, libraries and objects, you need a set of compiler > flags to be provided, and binaries possibly to be linked against. The kernel is much more dynamic in the configuration than most other project which is why building kernel modules needs interaction with the kernel. It is not enough to provide flags, we need the config too and the correct headers from a properly configured kernel tree etc. Things are a bit more complicated than just providing a single file would fix all cases. I will close this bug - but I will be happy to see a serie of patches to either get rid of VPATH and/or to introduce proper linux-dev-sdk support. Sam |