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 _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
