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

[Frans Meulenbroeks]

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?

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.

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).

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.
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/)

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.

Frans.
>
> --
> Tom Rini
> Mentor Graphics Corporation
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>