kernel-headers: lzma causing issues
PATCH 1/1 kernel-headers: lzma causing issues
The lzma patches really should be optional, so I've attached a patch which does exactly that.
I find myself having to remove the lzma patches because my build system doesn't natively have lzma. I tried to compensate for this by installing the latest lzma from gentoo's package tree, and apparently, it accepts different flags than the one these patches expect, so my kernel build still fails. Finally, I used the lzma from this buildroot and compiled it by hand, and it _mostly_ worked. Regardless, it seems silly to make this a requirement. Personally, I gzip my initramfs, and that's enough compression for me...
Please apply this patch and create a toolchain/kernel-headers/lzma directory and move the linux-*lzma*.patch files to that directory. I'm sure I can't be the only person who's had to simply delete those patches from my tree.
Thanks.
-Brad
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: kernel-headers-lzma-optional.diff
Url: http://busybox.net/lists/buildroot/attachments/20070814/3c555d82/attachment.diff
PATCH 1/1 kernel-headers: lzma causing issues
tis 2007-08-14 klockan 20:57 -0400 skrev Brad House:
Quoted 17 lines
The lzma patches really should be optional, so I've attached a patch which does exactly that.
I find myself having to remove the lzma patches because my build system doesn't natively have lzma. I tried to compensate for this by installing the latest lzma from gentoo's package tree, and apparently, it accepts different flags than the one these patches expect, so my kernel build still fails. Finally, I used the lzma from this buildroot and compiled it by hand, and it _mostly_ worked. Regardless, it seems silly to make this a requirement. Personally, I gzip my initramfs, and that's enough compression for me...
Please apply this patch and create a toolchain/kernel-headers/lzma directory and move the linux-*lzma*.patch files to that directory. I'm sure I can't be the only person who's had to simply delete those patches from my tree.
<snip>
Review
Quoted 9 lines
(quoted diff) +8
-0+config BR2_KERNEL_HEADERS_LZMA + bool "use lzma initramfs kernel patches" + default y + help + Apply patches which allow for lzma compressed + initramfs filesystems. This requires the lzma + program in your development environment. +
Since it also breaks unless you have lzma causing headache, I think the default should be to not use the lzma patch...
I am working on a new scheme where the target/linux and toolchain/kernel-headers are integrated, but this needs a lot more testing and will (as agreed with Bernhard be reviewed before applied, but it seems reasonable to do this as an intermediate fix.
BR
Ulf Samuelsson
PATCH 1/1 kernel-headers: lzma causing issues
Quoted 11 lines
Review
Quoted 8 lines
(quoted diff) +8
-0+config BR2_KERNEL_HEADERS_LZMA + bool "use lzma initramfs kernel patches" + default y + help + Apply patches which allow for lzma compressed + initramfs filesystems. This requires the lzma + program in your development environment. +Since it also breaks unless you have lzma causing headache, I think the default should be to not use the lzma patch...
ok, yeah, I'd agree with that ... I was just maintaining compatibility for those who are using it by defaulting to y.
Quoted 5 lines
I am working on a new scheme where the target/linux and toolchain/kernel-headers are integrated, but this needs a lot more testing and will (as agreed with Bernhard be reviewed before applied, but it seems reasonable to do this as an intermediate fix.
Ah, yeah, it would definitely make sense for those to be integrated. It took me a minute to realize the kernel headers version is what determined which release of the kernel got built ;)
Thanks.
-Brad
PATCH 1/1 kernel-headers: lzma causing issues
ons 2007-08-15 klockan 07:51 -0400 skrev Brad House:
Quoted 21 lines
Quoted 11 lines
Review
Quoted 8 lines
(quoted diff) +8
-0+config BR2_KERNEL_HEADERS_LZMA + bool "use lzma initramfs kernel patches" + default y + help + Apply patches which allow for lzma compressed + initramfs filesystems. This requires the lzma + program in your development environment. +Since it also breaks unless you have lzma causing headache, I think the default should be to not use the lzma patch...
ok, yeah, I'd agree with that ... I was just maintaining compatibility for those who are using it by defaulting to y.
Quoted 5 lines
I am working on a new scheme where the target/linux and toolchain/kernel-headers are integrated, but this needs a lot more testing and will (as agreed with Bernhard be reviewed before applied, but it seems reasonable to do this as an intermediate fix.
Quoted 4 lines
Ah, yeah, it would definitely make sense for those to be integrated. It took me a minute to realize the kernel headers version is what determined which release of the kernel got built ;)
In the stuff I am working on you can choose one out of three strategies. "tested" version (equivalent with the current kernel headers) "std" version linux-2.6.x and (with linux-2.6.y.z option) "experimental" version (latest stable, latest git or mm patch)
The current kernel headers will be applied automatically to the tested version, and can be choosen for the other versions. You can also add board specific patches (Before kernel headers are generated)
You can also add up to three patches located anywhere... Ideally that should be downloadable patches.
You also have choices for which version (vmlinux, zImage, uImage, bzImage) or freetext entry for linux target.
You can choose how to configure linux:
cp $(LINUX26_KCONFIG) .config ; make oldconfig
make <board>_defconfig
make ARCH=$(ARCH) xconfig
The Kernel headers will be built in $(STAGING_DIR) (or maybe $(TOOL_BUILD_DIR)) but the kernel will also be extracted in $(PROJECT_BUILD_DIR) and built from there.
Best Regards
Ulf Samuelsson