piggy broken in 2.5.24 build
At the end of make bzImage I get:
Quoted 11 lines
make[2]: Entering directory `/opt/kernel/linux-2.5.24/arch/i386/boot/compressed'
tmppiggy=_tmp_$$piggy; \
rm -f $tmppiggy $tmppiggy.gz $tmppiggy.lnk; \
objcopy -O binary -R .note -R .comment -S/opt/kernel/linux-2.5.24/vmlinux$tmppiggy; \
gzip -f -9 < $tmppiggy > $tmppiggy.gz; \
echo "SECTIONS { .data : {input_len= .;LONG(input_data_end - input_data)input_data= .; *(.data)input_data_end= .; }}" > $tmppiggy.lnk; \
ld -melf_i386-r -o piggy.o -b binary $tmppiggy.gz -b elf32-i386 -T $tmppiggy.lnk; \
rm -f $tmppiggy $tmppiggy.gz $tmppiggy.lnk/bin/sh:_tmp_18313piggy: No such file or directory
ld: cannot open _tmp_18313piggy.gz: No such file or directory
gcc -D__ASSEMBLY__ -D__KERNEL__ -I/opt/kernel/linux-2.5.24/include -traditional -chead.S
Quoted 8 lines
gcc -D__KERNEL__ -I/opt/kernel/linux-2.5.24/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=i686 -DKBUILD_BASENAME=misc -c
misc.cld -melf_i386-Ttext0x100000-estartup_32-o bvmlinux head.o misc.o piggy.o
ld: cannot open piggy.o: No such file or directory
make[2]: *** [bvmlinux] Error 1
make[2]: Leaving directory `/opt/kernel/linux-2.5.24/arch/i386/boot/compressed'
make[1]: *** [compressed/bvmlinux] Error 2
make[1]: Leaving directory `/opt/kernel/linux-2.5.24/arch/i386/boot'
make: *** [bzImage] Error 2
I tried zImage, with the same result.
Can I boot with just vmlinux?
jay
Quoted 1 line · sean darcy
At the end of make bzImage I get:
[output snipped]
Hi Sean.
I've tried to reproduce this without luck. Could you please mail me your .config. What shell are you using?
Sam
Quoted 21 lines · sean darcy
At the end of make bzImage I get:
Quoted 19 lines
make[2]: Entering directory `/opt/kernel/linux-2.5.24/arch/i386/boot/compressed'
tmppiggy=_tmp_$$piggy; \
rm -f $tmppiggy $tmppiggy.gz $tmppiggy.lnk; \
objcopy -O binary -R .note -R .comment -S/opt/kernel/linux-2.5.24/vmlinux$tmppiggy; \
gzip -f -9 < $tmppiggy > $tmppiggy.gz; \
echo "SECTIONS { .data : {input_len= .;LONG(input_data_end - input_data)input_data= .; *(.data)input_data_end= .; }}" > $tmppiggy.lnk; \
ld -melf_i386-r -o piggy.o -b binary $tmppiggy.gz -b elf32-i386 -T $tmppiggy.lnk; \
rm -f $tmppiggy $tmppiggy.gz $tmppiggy.lnk/bin/sh:_tmp_18313piggy: No such file or directory
ld: cannot open _tmp_18313piggy.gz: No such file or directory
gcc -D__ASSEMBLY__ -D__KERNEL__ -I/opt/kernel/linux-2.5.24/include -traditional -chead.S
gcc -D__KERNEL__ -I/opt/kernel/linux-2.5.24/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=i686 -DKBUILD_BASENAME=misc -cmisc.cld -melf_i386-Ttext0x100000-estartup_32-o bvmlinux head.o misc.o piggy.o
ld: cannot open piggy.o: No such file or directory
make[2]: *** [bvmlinux] Error 1
make[2]: Leaving directory `/opt/kernel/linux-2.5.24/arch/i386/boot/compressed'
make[1]: *** [compressed/bvmlinux] Error 2
make[1]: Leaving directory `/opt/kernel/linux-2.5.24/arch/i386/boot'
make: *** [bzImage] Error 2
At least I didn't break it, for a change. For all I can tell, the link of piggy.o fails, since the _tmp_xx.gz doesn't exist. That again doesn't exist since the _tmp_xx does not exist when gzipping it.
So the question is why does the objcopy ... line not generate the tmp_xx file. I don't see it spitting out any error either, but could you check the obvious, like remaining free space on that filesystem and /tmp?
BTW: I just rewrote that part so that it would at least properly stop at the place where the error occurs, but that still leaves the question as to what the actual error in your case is.
Quoted 1 line
Can I boot with just vmlinux?
Not unless you have a bootloader which supports that (i.e.: No.)
--Kai
Just a question about kbuild behaviour:
I compiled 2.5.24, with make dep, make bzImage, make modules.... After that, as usually, make dep; make bzImage ...doesn't change nor recompile anything After that, I changed an option with menuconfig, "VGA 16-color graphics console support",and "3DFX Banshee/Voodoo 3 display support" (because i can't see somethnig when i boot with it) from built-in to module. Then I run make dep; and it did make some small changes, as expected.
Then make bzImage compiled the entier kernel again, or at less a big big part of it, not only the changes made in menuconfig. make modules recompiled things again, wich are not affected with the changes (ie:
iptables modules).
My questions is:
It's not expected to do the same as 2.4 kernels, i mean, recompile only the changes made, not the entire thing?
PD: What are you doing with kbuild 2.5? What parts are you integrating? Wich parts you aren't going to integrate?
Quoted 14 lines · Diego Calleja
I compiled 2.5.24, with make dep, make bzImage, make modules.... After that, as usually, make dep; make bzImage ...doesn't change nor recompile anything After that, I changed an option with menuconfig, "VGA 16-color graphics console support",and "3DFX Banshee/Voodoo 3 display support" (because i can't see somethnig when i boot with it) from built-in to module. Then I run make dep; and it did make some small changes, as expected.
Then make bzImage compiled the entier kernel again, or at less a big big part of it, not only the changes made in menuconfig. make modules recompiled things again, wich are not affected with the changes (ie:
iptables modules).
Quoted 4 lines
My questions is:
It's not expected to do the same as 2.4 kernels, i mean, recompile only the changes made, not the entire thing?
If you toggled VGA 16-color support, that adds or removes the symbols from fbcon-vga-planes.c to the list of export symbols.
After the toggle, make dep detects that and adapts include/linux/modversions.h accordingly.
Now, if you "make" again, all files which include/linux/modversions.h need to be rebuilt, since it changed. And that's a lot of files, as you've noticed. The problem is that in reality, only a file which also *uses* one of these exported symbols really changes. But make cannot know that, so it recompiles everything which is possibly affected.
There's no easy way out from that, what you can of course do is turning off CONFIG_MODVERSIONS - in that case you'll see that only very little will be affected and rebuilt.
The fact that 2.4 recompiles little even in that case is since kbuild there has bugs in it which lead to it forgetting to recompile files (sometimes eventually resulting in "unresolved symbols in ...", which can only be cured with make mrproper).
For the current kbuild, you should never need to do make mrproper, it should always recognize changes and rebuild what's necessary.
Quoted 2 lines
PD: What are you doing with kbuild 2.5? What parts are you integrating? Wich parts you aren't going to integrate?
I'm currently still doing small bits, shipped files, asm-offsets generation and the like. I'm also preparing for separate build / src tree, which makes the current Makefiles and kbuild-2.5's Makefile.in's basically equivalent information-wise (though not syntactically).
If switching to kbuild-2.5's preprocessing phase will be necessary or make sense I do not even know myself yet. So some more patience is needed there.
--Kai
Quoted 5 lines · On Sat, 22 Jun 2002 16:08:45 -0500 (CDT) Kai Germaschewski…
Now, if you "make" again, all files which
include/linux/modversions.hneed to be rebuilt, since it changed. And that's a lot of files, as you've noticed. The problem is that in reality, only a file which also *uses* one of these exported symbols really changes. But make cannot know that, so it recompiles everything which is possibly affected.
This has a lot of sense ;), thanks