[oe] [OE-core] staging & using kernel headers
Richard Purdie
richard.purdie at linuxfoundation.org
Mon Mar 28 12:42:16 UTC 2011
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
More information about the Openembedded-devel
mailing list