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

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

[Tom Rini]

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

diff --git a/classes/base.bbclass b/classes/base.bbclass
index e0f9184..e26a45e 100644
--- a/classes/base.bbclass
+++ b/classes/base.bbclass
@@ -75,6 +75,12 @@ def base_dep_prepend(d):
  		if (bb.data.getVar('HOST_SYS', d, 1) !=
  	     	    bb.data.getVar('BUILD_SYS', d, 1)):
  			deps += " virtual/${TARGET_PREFIX}gcc virtual/libc "
+		elif bb.data.inherits_class('native', d) and \
+				bb.data.getVar('PN', d, True) not in \
+				("linux-libc-headers-native", "quilt-native",
+				 "unifdef-native", "shasum-native",
+				 "stagemanager-native", "coreutils-native"):
+			deps += " linux-libc-headers-native"
  	return deps

  DEPENDS_prepend="${@base_dep_prepend(d)} "
diff --git a/recipes/linux-libc-headers/linux-libc-headers.inc
b/recipes/linux-libc-headers/linux-libc-headers.inc
index 0487e65..0b0d05a 100644
--- a/recipes/linux-libc-headers/linux-libc-headers.inc
+++ b/recipes/linux-libc-headers/linux-libc-headers.inc
@@ -1,7 +1,8 @@
  DESCRIPTION = "Sanitized set of 2.6 kernel headers for the C library's
use."
  SECTION = "devel"
  LICENSE = "GPL"
+NATIVE_INSTALL_WORKS = "1"
+BBCLASSEXTEND = "native"

  RDEPENDS_${PN}-dev = ""
  RRECOMMENDS_${PN}-dbg = "${PN}-dev (= ${EXTENDPV})"
-
diff --git a/recipes/linux-libc-headers/linux-libc-headers_2.6.7.0.bb
b/recipes/linux-libc-headers/linux-libc-headers_2.6.7.0.bb
index b66e768..0a1159a 100644
--- a/recipes/linux-libc-headers/linux-libc-headers_2.6.7.0.bb
+++ b/recipes/linux-libc-headers/linux-libc-headers_2.6.7.0.bb
@@ -1,6 +1,7 @@
  require linux-libc-headers.inc

  INHIBIT_DEFAULT_DEPS = "1"
+NATIVE_INSTALL_WORKS = "0"
  PR = "r4"
  # NOTE: no need to package these headers, since the c library includes
them.
  PACKAGES = ""
diff --git a/recipes/linux-libc-headers/linux-libc-headers_2.6.8.1.bb
b/recipes/linux-libc-headers/linux-libc-headers_2.6.8.1.bb
index 4893cab..6cbd8ba 100644
--- a/recipes/linux-libc-headers/linux-libc-headers_2.6.8.1.bb
+++ b/recipes/linux-libc-headers/linux-libc-headers_2.6.8.1.bb
@@ -1,5 +1,6 @@
  require linux-libc-headers.inc

+NATIVE_INSTALL_WORKS = "0"
  HOMEPAGE = "http://ep09.pld-linux.org/~mmazur/linux-libc-headers/"
  # license note from the package:
  #   Linux-libc-headers are derived from linux kernel headers. For
license of a

-- 
Tom Rini
Mentor Graphics Corporation

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

[Khem Raj]

On Mon, Jun 7, 2010 at 12:33 PM, Tom Rini <tom_rini@mentor.com> wrote:
> 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.

could it be made optional so people who use distribution where this is not
needed are not penalized.

>
> [1]: A prime example of this would be mtd-utils-native and UBI
>
> diff --git a/classes/base.bbclass b/classes/base.bbclass
> index e0f9184..e26a45e 100644
> --- a/classes/base.bbclass
> +++ b/classes/base.bbclass
> @@ -75,6 +75,12 @@ def base_dep_prepend(d):
>                if (bb.data.getVar('HOST_SYS', d, 1) !=
>                    bb.data.getVar('BUILD_SYS', d, 1)):
>                        deps += " virtual/${TARGET_PREFIX}gcc virtual/libc "
> +               elif bb.data.inherits_class('native', d) and \
> +                               bb.data.getVar('PN', d, True) not in \
> +                               ("linux-libc-headers-native",
> "quilt-native",
> +                                "unifdef-native", "shasum-native",
> +                                "stagemanager-native", "coreutils-native"):
> +                       deps += " linux-libc-headers-native"
>        return deps
>
>  DEPENDS_prepend="${@base_dep_prepend(d)} "
> diff --git a/recipes/linux-libc-headers/linux-libc-headers.inc
> b/recipes/linux-libc-headers/linux-libc-headers.inc
> index 0487e65..0b0d05a 100644
> --- a/recipes/linux-libc-headers/linux-libc-headers.inc
> +++ b/recipes/linux-libc-headers/linux-libc-headers.inc
> @@ -1,7 +1,8 @@
>  DESCRIPTION = "Sanitized set of 2.6 kernel headers for the C library's
> use."
>  SECTION = "devel"
>  LICENSE = "GPL"
> +NATIVE_INSTALL_WORKS = "1"
> +BBCLASSEXTEND = "native"
>
>  RDEPENDS_${PN}-dev = ""
>  RRECOMMENDS_${PN}-dbg = "${PN}-dev (= ${EXTENDPV})"
> -
> diff --git a/recipes/linux-libc-headers/linux-libc-headers_2.6.7.0.bb
> b/recipes/linux-libc-headers/linux-libc-headers_2.6.7.0.bb
> index b66e768..0a1159a 100644
> --- a/recipes/linux-libc-headers/linux-libc-headers_2.6.7.0.bb
> +++ b/recipes/linux-libc-headers/linux-libc-headers_2.6.7.0.bb
> @@ -1,6 +1,7 @@
>  require linux-libc-headers.inc
>
>  INHIBIT_DEFAULT_DEPS = "1"
> +NATIVE_INSTALL_WORKS = "0"
>  PR = "r4"
>  # NOTE: no need to package these headers, since the c library includes
> them.
>  PACKAGES = ""
> diff --git a/recipes/linux-libc-headers/linux-libc-headers_2.6.8.1.bb
> b/recipes/linux-libc-headers/linux-libc-headers_2.6.8.1.bb
> index 4893cab..6cbd8ba 100644
> --- a/recipes/linux-libc-headers/linux-libc-headers_2.6.8.1.bb
> +++ b/recipes/linux-libc-headers/linux-libc-headers_2.6.8.1.bb
> @@ -1,5 +1,6 @@
>  require linux-libc-headers.inc
>
> +NATIVE_INSTALL_WORKS = "0"
>  HOMEPAGE = "http://ep09.pld-linux.org/~mmazur/linux-libc-headers/"
>  # license note from the package:
>  #   Linux-libc-headers are derived from linux kernel headers. For
> license of a
>
> --
> Tom Rini
> Mentor Graphics Corporation
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

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

[Chris Larson]

On Mon, Jun 7, 2010 at 2:21 PM, Khem Raj <raj.khem@gmail.com> wrote:

> On Mon, Jun 7, 2010 at 12:33 PM, Tom Rini <tom_rini@mentor.com> wrote:
> > 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.
>
> could it be made optional so people who use distribution where this is not
> needed are not penalized.
>

You mean like ASSUME_PROVIDED += "linux-libc-headers-native"?
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

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

[Khem Raj]

On (07/06/10 14:31), Chris Larson wrote:
> On Mon, Jun 7, 2010 at 2:21 PM, Khem Raj <raj.khem@gmail.com> wrote:
> 
> > On Mon, Jun 7, 2010 at 12:33 PM, Tom Rini <tom_rini@mentor.com> wrote:
> > > 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.
> >
> > could it be made optional so people who use distribution where this is not
> > needed are not penalized.
> >
> 
> You mean like ASSUME_PROVIDED += "linux-libc-headers-native"?

heh sure,I had that in mind but I was thinking if it was otherway around
where the distros which new these headers have to specify to include them
and not the ones which already have them.


> -- 
> Christopher Larson
> clarson at kergoth dot com
> Founder - BitBake, OpenEmbedded, OpenZaurus
> Maintainer - Tslib
> Senior Software Engineer, Mentor Graphics
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

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

[Frans Meulenbroeks]

2010/6/7 Tom Rini <tom_rini@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).

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.

Just my eur 0.02

Frans.

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

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

[Khem Raj]

On Mon, Jun 7, 2010 at 11:36 PM, Frans Meulenbroeks
<fransmeulenbroeks@gmail.com> wrote:
> 2010/6/7 Tom Rini <tom_rini@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.

no. mtd-utils-native itself is a host utility so to build it we need tools
and development files for the host not the target.

>
> What would be the difference between linux-libc-headers and
> linux-libc-headers-native in the first place?

one is for target (e.g. arm) and another one would be your build system
(e.g. x86)

> (and if there is a difference, I think a better package name would be
> linux-libc-headers-cross).

cross is for something which runs on host and generates code for target


>
> 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.
>
> Just my eur 0.02
>
> Frans.
>
> 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).
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

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

[Tom Rini]

Frans Meulenbroeks wrote:
> 2010/6/7 Tom Rini <tom_rini@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.

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

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

-- 
Tom Rini
Mentor Graphics Corporation

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

[Frans Meulenbroeks]

2010/6/8 Tom Rini <tom_rini@mentor.com>:
> Frans Meulenbroeks wrote:
>>
>> 2010/6/7 Tom Rini <tom_rini@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@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: [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@mentor.com>:
>> Frans Meulenbroeks wrote:
>>> 2010/6/7 Tom Rini <tom_rini@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

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

[Tom Rini]

Tom Rini wrote:
> 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

ping?  The summary of the feedback, I believe would be:
- Can we just make this opt-in for distros that need it?
- Can we easily opt out if we don't?

For the second, yes, ASSUME_PROVIDED still works.  For the first, I'd 
argue that doing so is a lot harder (at least without some additional 
infrastructure and reliance on other external tools) than just adding 
another early package.

So, yay or nay?

> 
> diff --git a/classes/base.bbclass b/classes/base.bbclass
> index e0f9184..e26a45e 100644
> --- a/classes/base.bbclass
> +++ b/classes/base.bbclass
> @@ -75,6 +75,12 @@ def base_dep_prepend(d):
>          if (bb.data.getVar('HOST_SYS', d, 1) !=
>                   bb.data.getVar('BUILD_SYS', d, 1)):
>              deps += " virtual/${TARGET_PREFIX}gcc virtual/libc "
> +        elif bb.data.inherits_class('native', d) and \
> +                bb.data.getVar('PN', d, True) not in \
> +                ("linux-libc-headers-native", "quilt-native",
> +                 "unifdef-native", "shasum-native",
> +                 "stagemanager-native", "coreutils-native"):
> +            deps += " linux-libc-headers-native"
>      return deps
> 
>  DEPENDS_prepend="${@base_dep_prepend(d)} "
> diff --git a/recipes/linux-libc-headers/linux-libc-headers.inc
> b/recipes/linux-libc-headers/linux-libc-headers.inc
> index 0487e65..0b0d05a 100644
> --- a/recipes/linux-libc-headers/linux-libc-headers.inc
> +++ b/recipes/linux-libc-headers/linux-libc-headers.inc
> @@ -1,7 +1,8 @@
>  DESCRIPTION = "Sanitized set of 2.6 kernel headers for the C library's
> use."
>  SECTION = "devel"
>  LICENSE = "GPL"
> +NATIVE_INSTALL_WORKS = "1"
> +BBCLASSEXTEND = "native"
> 
>  RDEPENDS_${PN}-dev = ""
>  RRECOMMENDS_${PN}-dbg = "${PN}-dev (= ${EXTENDPV})"
> -
> diff --git a/recipes/linux-libc-headers/linux-libc-headers_2.6.7.0.bb
> b/recipes/linux-libc-headers/linux-libc-headers_2.6.7.0.bb
> index b66e768..0a1159a 100644
> --- a/recipes/linux-libc-headers/linux-libc-headers_2.6.7.0.bb
> +++ b/recipes/linux-libc-headers/linux-libc-headers_2.6.7.0.bb
> @@ -1,6 +1,7 @@
>  require linux-libc-headers.inc
> 
>  INHIBIT_DEFAULT_DEPS = "1"
> +NATIVE_INSTALL_WORKS = "0"
>  PR = "r4"
>  # NOTE: no need to package these headers, since the c library includes
> them.
>  PACKAGES = ""
> diff --git a/recipes/linux-libc-headers/linux-libc-headers_2.6.8.1.bb
> b/recipes/linux-libc-headers/linux-libc-headers_2.6.8.1.bb
> index 4893cab..6cbd8ba 100644
> --- a/recipes/linux-libc-headers/linux-libc-headers_2.6.8.1.bb
> +++ b/recipes/linux-libc-headers/linux-libc-headers_2.6.8.1.bb
> @@ -1,5 +1,6 @@
>  require linux-libc-headers.inc
> 
> +NATIVE_INSTALL_WORKS = "0"
>  HOMEPAGE = "http://ep09.pld-linux.org/~mmazur/linux-libc-headers/"
>  # license note from the package:
>  #   Linux-libc-headers are derived from linux kernel headers. For
> license of a


-- 
Tom Rini
Mentor Graphics Corporation

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

[Leon Woestenberg]

Hello Tom,

On Tue, Jun 15, 2010 at 7:48 PM, Tom Rini <tom_rini@mentor.com> wrote:
> For the second, yes, ASSUME_PROVIDED still works.  For the first, I'd argue
> that doing so is a lot harder (at least without some additional
> infrastructure and reliance on other external tools) than just adding
> another early package.
>
> So, yay or nay?
>
I would say the ASSUME_PROVIDED for the native linux headers should be
mentioned in the local.conf.sample,
commented out, so that users can enable it easily (optimize the build
like Khem says).

Could you add that to the patch, or as a follow-up patch?

Acked-by: Leon Woestenberg <leon@sidebranch.com>

Regards,
-- 
Leon

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

[Tom Rini]

Leon Woestenberg wrote:
> Hello Tom,
> 
> On Tue, Jun 15, 2010 at 7:48 PM, Tom Rini <tom_rini@mentor.com> wrote:
>> For the second, yes, ASSUME_PROVIDED still works.  For the first, I'd argue
>> that doing so is a lot harder (at least without some additional
>> infrastructure and reliance on other external tools) than just adding
>> another early package.
>>
>> So, yay or nay?
>>
> I would say the ASSUME_PROVIDED for the native linux headers should be
> mentioned in the local.conf.sample,
> commented out, so that users can enable it easily (optimize the build
> like Khem says).
> 
> Could you add that to the patch, or as a follow-up patch?

As a follow-up:
--- a/conf/local.conf.sample
+++ b/conf/local.conf.sample
@@ -30,6 +30,11 @@ BBFILES := "${@bb.fatal('Edit your conf/local.conf: 
BBFILES')}"
  # This is a regulary expression, so be sure to get your parenthesis 
balanced.
  BBMASK = ""

+# Uncomment this if your host distribution has recent enough Linux
+# Kernel header files.  Utilities we use to generate certain types of
+# target filesystems need somewhat recent header files.
+# ASSUME_PROVIDED += "linux-libc-headers-native"
+
  # Uncomment this if you want to use a prebuilt toolchain. You will need to
  # provide packages for toolchain and additional libraries yourself. 
You also
  # have to set PATH in your environment to make sure BitBake finds 
additional binaries.

-- 
Tom Rini
Mentor Graphics Corporation

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

[Frans Meulenbroeks]

2010/6/16 Tom Rini <tom_rini@mentor.com>:
> Leon Woestenberg wrote:
>>
>> Hello Tom,
>>
>> On Tue, Jun 15, 2010 at 7:48 PM, Tom Rini <tom_rini@mentor.com> wrote:
>>>
>>> For the second, yes, ASSUME_PROVIDED still works.  For the first, I'd
>>> argue
>>> that doing so is a lot harder (at least without some additional
>>> infrastructure and reliance on other external tools) than just adding
>>> another early package.
>>>
>>> So, yay or nay?
>>>
>> I would say the ASSUME_PROVIDED for the native linux headers should be
>> mentioned in the local.conf.sample,
>> commented out, so that users can enable it easily (optimize the build
>> like Khem says).
>>
>> Could you add that to the patch, or as a follow-up patch?
>
> As a follow-up:
> --- a/conf/local.conf.sample
> +++ b/conf/local.conf.sample
> @@ -30,6 +30,11 @@ BBFILES := "${@bb.fatal('Edit your conf/local.conf:
> BBFILES')}"
>  # This is a regulary expression, so be sure to get your parenthesis
> balanced.
>  BBMASK = ""
>
> +# Uncomment this if your host distribution has recent enough Linux
> +# Kernel header files.  Utilities we use to generate certain types of
> +# target filesystems need somewhat recent header files.
> +# ASSUME_PROVIDED += "linux-libc-headers-native"
> +
>  # Uncomment this if you want to use a prebuilt toolchain. You will need to
>  # provide packages for toolchain and additional libraries yourself. You
> also
>  # have to set PATH in your environment to make sure BitBake finds
> additional binaries.
>
> --
> Tom Rini
> Mentor Graphics Corporation

Suggest to write a separate email with a catchy title telling people
that this change becomes in effect (after the commit is done).
rationale: after the change is made, people will get the headers by
default, and not everyone reads this thread.

Frans