[OE-core] [PATCH] linux-libc-headers: Add big warning about antisocial behaviour

Anders Darander anders at chargestorm.se
Mon Sep 16 10:08:03 UTC 2013


* Khem Raj <raj.khem at gmail.com> [130914 06:24]:



> On Friday, September 13, 2013, Richard Purdie wrote:

>     I'm getting concerned with the number of people forking this recipe
>     and not understanding what they're doing. I'm therefore proposing
>     adding in a suitable warning to people thinking of copying it.

>     Signed-off-by: Richard Purdie <richard.purdie at linuxfoundation.org>
>     ---
>     diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
>     b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
>     index 96fe2ff..79b7dc4 100644
>     --- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
>     +++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
>     @@ -2,6 +2,28 @@ DESCRIPTION = "Sanitized set of kernel headers for the C
>     library's use."
>      SECTION = "devel"
>      LICENSE = "GPLv2"

>     +#########################################################################
>     +####                        PLEASE READ
>     +#########################################################################
>     +#
>     +# You're probably looking here thinking you need to create some new copy
>     +# of linux-libc-headers since you have your own custom kernel. To put
>     +# this simply, you DO NOT.
>     +#
>     +# Why? These headers are used to build the libc. If you customise the
>     +# headers you are customising the libc and the libc becomes machine
>     +# specific. Most people do not add custom libc extensions to the kernel
>     +# and have a machine specific libc.
>     +#
>     +# But you have some kernel headers you need for some driver? That is fine
>     +# but get them from STAGING_KERNEL_DIR where the kernel installs itself.
>     +# This will make the package using them machine specific but this is much
>     +# better than having a maching specific C library. This does mean your
>     +# recipe needs a DEPENDS += "virtual/kernel" but again, that is fine and
>     +# makes total sense.
>     +#
>     +# -- RP


> There are cases where we have bsps with 2.6.3x kernels and libc compiled
> against 3.10 assumes syscalls
> Which the kernel will not provide. These kinds are genuine cases for creating
> equivalent recipes
> You should mention the valid case too in this notice and basically asses the
> user is knowing what. He is doing

I'd be inclined to say that anyone working on / adding a bsp that needs
this, will (hopefully) understand this anyway. If you know that
3.x-based kernel headers aren't working, you're going to add a patched
linux-libc-headers regardless of the warning above.

Cheers,
Ander

-- 
Anders Darander
ChargeStorm AB / eStorm AB



More information about the Openembedded-core mailing list