kernel headers question.

[Dave Johnson]

Steven W. Orr writes:
> =>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?

x86 should be rather good between 2.4 and 2.6, but other architectures
may be more different and have conflicts however I don't recall any
issues.

You may run into problems building the latest and greatest glibc
against 2.4 headers as it may be looking for new syscalls such as
sched_getaffinity() which were added in 2.6.

> =>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?

In order to build shared versions of libraries ld needs crt1.o as well
as -lc (both built as part of *libc) to link a .so.  So more correctly
I should have said --enable-shared (highly desirable in stage 2)
requires glibc although I recall c++ may also need it.

I just ran a build skipping glibc and the first failure in stage 2 was
building libgcc_s.so.1 because it couldnt' find crt1 and libc.

> =>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.

see above.

-- 
Dave