Messages in this thread | | | Date | Thu, 08 Jul 1999 06:10:59 +0200 | From | Steffen Evers <> | Subject | Re: script for compiling the kernel |
| |
Hi Riley.
Riley Williams wrote: > [...] > > I wanted to do it this way: compile -> check for 'kernel to big' > > -> recompile The question is: which steps do I have to repeat: > > dep ? clean ? I don't think so but is there anyone who could > > confirm this FOR SURE ? > > [...] > All the patch does is to move tools/build from the very end of the > dependancy listings to immediately after the beginning thereof, so it > should be impossible for it to cause any problems. > > The result of that patch is to guarantee that (A) all items compiled > by both "make zImage" and "make bzImage" are compiled before any of > the items unique to that method, and (B) tools/build is the last > common item to be compiled in both cases. This allows the existence or > otherwise of tools/build to be used to determine whether the fault was > in the common items or not, if compilation failed. They only reason I know so fare that compilation could fail for zImage and NOT for bzImage is that the kernel gets to big. So, if 'make zImage' fails and there is no message 'kernel to big' it should be in the 'common part', right ? So I think it's much easier to use the log file that I've saved anyway and look for this message: 'kernel too big'. The advantage for this is: - don't need a patch for the Makefile (VERY IMPORTANT, think of newcomers) - don't need to know so much about what really happens during make (b)zImage and you are not affected by any changes Disadvantages: - mkkrl is lost when someone find the message 'kernel too big' boring and replaces it with 'kernel IS too big' - if someone gives a message with 'kernel too big' in it mkkrl mistakes this as our bzImage flag But I think it's ok.
> Given that, the following script has worked reliably for me... > [...] > Q> if grep CONFIG_MODULES .config | grep '=y' > /dev/null ; then > Q> make modules modules_install This might be a good idea, I haven't thought of people not using modules.
> Q> fi > Q> rm -f arch/i386/tools/build > Q> make zImage > Q> if [ -f arch/i386/tools/build -a ! -f arch/i386/boot/zImage ]; then > Q> make bzImage > Q> fi > > Does that answer your question? Yes and no. Looking at your script I can see that you assume that you don't need to (re)make a dep and clean as you don't use it after zImage fails.
But my question was to be accurate: Is there ANY case that zImage fails with 'kernel too big' where you should do a 'make dep' or 'make clean' before 'make bzImage' ?
> > > By the way, I was thinking of a database or something that makes > > the whole building process inclusive configuration a little bit > > easier. E.g. storeing the name of the hardware component that > > this feature is for. Like this many options could just be hidden > > and everything would be so much easier. But it's a lot of work > > ... and I've got so little time ... > > Note that there are two types of scenario that any setup script will > need to deal with... > > 1. Compiling on the system it is to be run on. > > 2. Compiling on a different system to the one it is to be run on. > > In the first type of scenario, it should be possible for most of the > configuration to be done automatically, but in the second, there is > probably little that can be done without user assistance... > [...] I haven't thought of the 2nd. You are right, but still ... for people who just want to get a lean kernel it could be easier ... E.g.: I wanted to use my SB PCI 64V sound card and I'm STILL not sure which options I have to set. There are so many contradicting statements in the internet.
Best wishes,
Steffen
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |