Re: [oe] staging & using kernel headers

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Fri, 2011-03-25 at 17:02 +0100, Michael Jones wrote:
> On 03/25/2011 03:55 PM, Richard Purdie wrote:
> > On Fri, 2011-03-25 at 15:14 +0100, Michael Jones wrote:
> > Ok, so you only really have the options of:
> > 
> > a) Use a specific patched kernel for linux-libc-headers which has these
> > headers in it (see below for why this is ugly)
> > b) Install some extra headers in "libc-headers-extras" type recipe
> > c) Ship default versions of the headers with your userspace and use
> > those if shared versions don't exist. This assumes the API is stable and
> > on its way to mainline.
> > 
> > I don't think this is as common a requirement as you think as most
> > people get this kind of thing merged into the mainline kernel to try and
> > reduce this kind of problem.
> 
> To clarify, it's not that I have a custom patched kernel I need to use.
>  I am following V4L2 development, so I am using a new kernel from those
> developers.  V4L2 changes do of course move upstream.

Ok, sorry, I was lacking context here.
 
> > The ugliness is where you have two different arm boards you want to
> > build, with a common optimisation/toolchain and each wants to redirect
> > linux-libc-headers to its own "special" version. The question is then,
> > why aren't the "special" bits in mainline.
> 
> 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.

> I only stumbled upon this because the gstreamer-ti recipes were pointing
> at internal kernel headers, but because these are user-space apps, they
> should actually be using the linux-libc-headers.  Right?

Ideally, yes. I know under some circumstances, they might want to poke
into internal kernel headers but that is really a design issue that
needs fixing.

Cheers,

Richard