[oe] [PATCH, RFC] Add linux-libc-headers-native, make it default dep for native

[Tom Rini]

Frans Meulenbroeks wrote:
> 2010/6/8 Tom Rini <tom_rini at mentor.com>:
>> Frans Meulenbroeks wrote:
>>> 2010/6/7 Tom Rini <tom_rini at mentor.com>:
>>>> On some host distributions the provided linux kernel headers are too old
>>>> to compile utilities we need[1].  Given that we need these utilities to
>>>> run things on the target the best solution is to provide
>>>> linux-libc-headers-native.  Rather than get things into an inconsistent
>>>> state, we make linux-libc-headers-native be a default dependency.
>>>>
>>>> [1]: A prime example of this would be mtd-utils-native and UBI
>>> I'd say this is heading in the totally wrong direction.
>>>
>>> Target code should not depend on host headers.
>>> And if you need the target headers, you should depend on and use
>>> linux-libc-headers.
>>>
>>> I guess mtd-utils-native is used to make an mtd image for the target
>>> and as such I would expect it to use the target headers.
>>>
>>> What would be the difference between linux-libc-headers and
>>> linux-libc-headers-native in the first place?
>>> (and if there is a difference, I think a better package name would be
>>> linux-libc-headers-cross).
>> As Khem said, you're thinking in the wrong direction here.  Target stuff
>> which needs the headers get the headers via linux-libc-headers.  The problem
>> is runs on the host tools that generate things for the target.
> 
> I understand what you are saying (I think :-) )
> For me ubi stuff (and mkfs.jffs2) in mtd-utils-native are tools which
> generate code (in this case an image) for the target. That is why I
> assumed them to require target headers (but see below).
> 
> (offtopic observation: mtd-utils-native delivers also a lot of stuff
> that is not really interesting for native (flash-erase, nandwrite,
> ...)
> 
> 
>>> Btw if say mtd-utils-native needs kernel headers to access host
>>> functionality using headers for a different kernel version seems to be
>>> a no-no either.
>> mtd-utils is depending on OK to be exported by the kernel information to
>> know how to make a UBI image.  And again, for the target this just works.
> 
> What do you mean with OK?

As in headers which are clean and allowed to be used by userspace.

> Actually I guess it is also unclear to me what version of
> linux-libc-headers you want to install and I feel if they are from a
> different version than the native version, the native code should
> *not* depend on it, as it might give rise to wrong assumptions.

It is up to the distribution to pick this version, just like it is for 
the target.

> And if we are only talking about a missing data structure or define or
> so, it might be possible to add a patch to mtd-utils-native to fix
> that. (can't judge that as I am lacking info on what part of
> linux-libc-headers would be needed).

No, it's a massive headache.  We went that route first.

> 
> If the stuff needed is there to miss
> 
>>> PS: which distributions/distribution versions/kernel versions do have
>>> this problem?
>>> Ubuntu 8.04 (which has a 2.6.24 kernel) does not seem to exhibit this
>>> problem).
>> RHEL4.
> 
> Ouch. That brings up another question.
> RHEL4 is 2.6.9 iirc. I can imagine ubi tools and 2.6.9 do not go
> together too well.

Nope, it works great.  We aren't trying to use these UBI images on 
RHEL4, we're using them on target hardware that's running a kernel with 
UBI support.

> Do we want to do something as drastic as linux-libc-headers-native to
> support a fairly outdated kernel/distro.
> I have some doubts here.(btw RHEL4 is already on minimal support and
> is EOL feb 29, 2012).(http://www.redhat.com/security/updates/errata/)

Yes, it's not EOL for another year and a half plus which means quite a 
lot of people are going to be using it for another year and a half plus. 
  I also really don't see this as drastic.  The only reason it's more 
than a one-liner is that once you have this, other -native recipes that 
are in do_compile can get mad about header versions changing under them 
(or being installed at just the wrong point in a compile, and other fun 
races).

> I guess this could also be solved locally. E.g. making a RHEL4
> specific recipe to install the headers, or to have copies of the
> needed headers in some place and add them to the inc search path
> Guess this: http://wiki.openembedded.net/index.php/OEandYourDistro#CentOS_4.4_.2F_Red_Hat_Enterprise_Linux_4
> could be extended with some extra instructions.

IMHO, that seems rather drastic.  If we don't want to cleanly / fully 
support RHEL4, I can just stop posting these kind of things.  It's not 
my favorite build host either :)

-- 
Tom Rini
Mentor Graphics Corporation