This is a patch for linux-headers-2.4.20 that allows the headers to be installed as normal or in/usr/$CCHOST/include for a cross compiler tool chain. Reproducible: Always Steps to Reproduce: 1. emerge linux-headers Puts the kernel headers in /usr/include/{asm,linux} 2. CCHOST=sparc-unknown-linux-headers emerge linux-headers Puts the headers is /usr/$CCHOST/include/{asm,linux} This is suitable for a cross tool chain prefix of /usr This was not intented for here but I could never get this ebuild to put the sparc asm files in include/asm, only in include/sparc or include/sparc64 so I redid a lot of src_install(). When running make oldconfig it is possible to get the correct asm link put in place with yes "" | make ARCH=sparc oldconfig This saves guesing which asm directory to copy. Just copy include/asm/* to ${D}/usr/include/asm.
Created attachment 9714 [details, diff] path for linux-headers-2.4.20
This ebuild has my full endorsement. I had made a change to the kernel.eclass to fix the headers source directory in the same fashion; it seems that such a change is correct.
Looks fine to me as well. Commit a ~ version that can be tested.
Created attachment 9747 [details, diff] less radical modification to the ebuild Changes have been made to the main linux-headers so that a less radical change seems to be needed for me to get the appropriate headers for sparc.
Created attachment 10242 [details] linux-headers-2.4.20 This time I included the complete ebuild. I was based it on linux-headers-2.4.20. The linux-headers-2.4.20.ebuild has since been removed.
Created attachment 10897 [details, diff] kernel.eclass.patch Here's a patch for the kernel.eclass, diff'd against current cvs.
The kernel.eclass I have been using is very simillar. Any -headers ebuild that uses kernel.eclass does not need any modifications for the headers to be moved to the correct location when building a cross tool chain. Saves having to modify each -headers ebuilds.
With the addition of kernel-2.eclass is this still necessary? Or have the changes been made already?
The kernel eclasses already take care of this. Marking as fixed.