kernel headers question.

[Steven W. Orr]

On Sunday, Aug 20th 2006 at 13:50 -0400, quoth Dave Johnson:

=>Steven W. Orr writes:
=>> So having said all that, is it safe to say that for all versions of
=>> 2.4 and 2.6 series kernels, it's ok to have one old version of
=>> glibc-kernheaders? Or is there some reason that I am constrained to
=>> having seperate kernel headers for each project thereby necessitating
=>> that each version of gcc, binutils, and UClibc is dependant on the
=>> version of linux that it will run against?
=>
=>
=>When building gcc/binutils you generally do not need the specific
=>version of the kernel headers (or more specifically
=>--with-headers=<something> from gcc's configure line).

So far so good.

=>The only really linux specific part in gcc/binutils is the crt*.o
=>.  Even libgcc.a, libiberty.a, libstdc++.a aren't very kernel
=>specific, but do require something in the lines of header files to
=>build.
=>
=>I generally use something along the lines of:
=>
=>construct sys include from a 'close-enough kernel'

This is probably really the heart of the question. Is any early 2.4 set of 
headers going to be good enough for any *libc to be run on any 2.4 series 
that is equal to or later than the set of headers used? Do I need to have 
a different set for 2.6 kernels or can I continue use of the headers that 
came from a 2.4 kernel?

=>build binutils cross
=>build gcc cross stage 1 (only c support)
=>build glibc cross
=>build gcc cross stage 2 (c & c++)
=>blow away this glibc results
=>install stage 2 gcc, binutils, and sys includes system wide.
=>
=>(if you want c++ support you unfortunately need to build a cross
=>libc inbetween stage 1 and 2.)

I don't understand why?

=>
=>The specific kernel headers are more important when building your
=>*libc as any change in the syscall area has a big effect on libc.

Agreed, but I'm not sure I understand why syscall comes into play. I get 
that there are constants to syscall that correspond to new system calls in 
newer kernels, but I'm not sure I understand why i care.

=>Note that this part has settled down a long time ago and you can
=>usually get away with a close-enough kernel here too.  If you're not
=>changing syscalls or other kernel headers then you can build your
=>*libc once and forget it.
=>
=>workareas consist of:
=>
=>build kernel
=>build *libc  (rebuilding isn't needed that often)
=>build everything else
=>
=>If you're not changing your libc or major changes in your kernel (that
=>would effect *libc) you can build the libc and install it system wide
=>along with gcc/bintuils.

I see a glimmer of hope.

=>
=>Also note, you need to make sure binutils and gcc dont look in
=>/usr/include or /usr/lib by default, but instead uses your sys includes
=>you build with and the libgcc.a, libiberty.a and libstdc++.a that you
=>built.

Definitely agreed.

=>
=>
=>-- 
=>Dave

Thanks. :-)

-- 
Time flies like the wind. Fruit flies like a banana. Stranger things have  .0.
happened but none stranger than this. Does your driver's license say Organ ..0
Donor?Black holes are where God divided by zero. Listen to me! We are all- 000
individuals! What if this weren't a hypothetical question?
steveo at syslang.net