From: Michael Jones <michael.jones@matrix-vision.de>
To: openembedded-devel@lists.openembedded.org
Cc: koen@dominion.thruhere.net, openembedded-core@lists.openembedded.org
Subject: Re: [oe] staging & using kernel headers
Date: Wed, 06 Apr 2011 17:47:15 +0200 [thread overview]
Message-ID: <4D9C8B03.8080008@matrix-vision.de> (raw)
In-Reply-To: <1301316136.3018.189.camel@rex>
Sorry for the delay, I overlooked the last 2 replies because I was no
longer in to: or cc: :(
On 03/28/2011 02:42 PM, Richard Purdie wrote:
> 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.
Isn't it the other way around? Steffen Sledz had the opposite problem
as me in Feb
(http://www.mail-archive.com/openembedded-devel%40lists.openembedded.org/msg16022.html)
because he's using a kernel older than the linux-libc-headers. He
quotes the kernel doc: "This means that a program built against a C
library using older kernel headers should run on a newer kernel"
>
>> 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
>
-Michael
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
prev parent reply other threads:[~2011-04-06 15:58 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4D832AA4.1020701@matrix-vision.de>
2011-03-18 9:55 ` staging & using kernel headers Koen Kooi
2011-03-25 13:38 ` Richard Purdie
2011-03-25 14:14 ` Michael Jones
2011-03-25 14:55 ` Richard Purdie
2011-03-25 16:02 ` Michael Jones
2011-03-28 12:42 ` [oe] " Richard Purdie
2011-03-28 16:39 ` Khem Raj
2011-04-07 13:03 ` Michael Jones
2011-04-06 15:47 ` Michael Jones [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D9C8B03.8080008@matrix-vision.de \
--to=michael.jones@matrix-vision.de \
--cc=koen@dominion.thruhere.net \
--cc=openembedded-core@lists.openembedded.org \
--cc=openembedded-devel@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox