[OE-core] [oe] staging & using kernel headers

[Michael Jones]

On 03/28/2011 06:39 PM, Khem Raj wrote:
> On Mon, Mar 28, 2011 at 5:42 AM, Richard Purdie
> <richard.purdie at linuxfoundation.org> wrote:
>>
>>> OK, so here's what I'm realizing, please correct me if I'm wrong:
>>> What I did unconventionally (ie. wrong) was to use a kernel version
>>> newer than my linux-libc-headers were.  I should create a new
>>> linux-libc-headers recipe, as I had done with the kernel recipe, and
>>> build glibc and linux-libc-headers using my 2.6.38 kernel.
>>
>> We should *always* be using linux-libc-headers >= to the kernel version
>> being used.
>>
> 
> If you use newer kernel should work ok why is that a problem ? kernel
> syscalls are backward compatible
> and we use oldest kernel version of like 2.6.16 for eglibc to build
> against so it should not be a problem
> to use different versions for kernel and kernel-headers. I think your
> problem lies elsewhere
> 

There is a kernel interface in the V4L2 development tree that is being
introduced in 2.6.39 (but which in my local branch is patched on top of
2.6.38).  The problem I kicked off this thread with was due to ti-dmai
and gstreamer-ti _directly_ using the headers from this kernel, which
since 2.6.32 gives a warning for doing so.

Of course, I'm using the newer kernel for a reason, which is to use the
new kernel API.  So I need to use the headers from my local development
kernel (built by an OE recipe) when building that application, which I'm
now writing the recipe for.  I thought at first that userspace apps were
automatically built against the headers derived from the kernel being
used (which is what the ti recipes do, but incorrectly).  During this
thread I realized that linux-libc-headers is a separate recipe intended
for supplying user headers.

I suppose I will use the method for my V4L2 app that I kicked off this
thread with- staging the development kernel's headers with make_install
somewhere which can be used by my app.  As Richard pointed out earlier
in this thread, making the package dependent on the kernel makes the
package machine dependent.  This is OK for this package, but I still
want all other apps to be Angstrom-generic apps, so I don't want to
change linux-libc-headers to use my kernel headers after all.

MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner