* Re: staging & using kernel headers [not found] <4D832AA4.1020701@matrix-vision.de> @ 2011-03-18 9:55 ` Koen Kooi 2011-03-25 13:38 ` Richard Purdie 0 siblings, 1 reply; 9+ messages in thread From: Koen Kooi @ 2011-03-18 9:55 UTC (permalink / raw) To: Michael Jones Cc: openembedded-devel, Patches and discussions about the oe-core layer CC:ing oe-core since we have kernel.bbclass patches there as well. Op 18 mrt 2011, om 10:49 heeft Michael Jones het volgende geschreven: > Hello Koen & co., > > I recently bumped into a problem with recipes ti-dmai and gstreamer-ti > when they included the kernel headers. These headers were staged by > kernel.bbclass sysroot_stage_all_append() with a lot of manual copying > and manipulating links and such, rather than using 'oe_runmake > headers_install'. Back in October Koen explained this > (http://article.gmane.org/gmane.comp.handhelds.openembedded/37772) is > because some recipes use private kernel API. The result of this with my > 2.6.38 kernel DMAI and gst-ti don't really work with anything newer than 2.6.32-psp, we're trying to get that addressed internally. > is that I get a warning-turned-error from linux/types.h > that "Attempt to use kernel headers from user space". > > ti-dmai_svn.bb hacks this (self-admittedly) by defining > _EXPORTED_HEADERS_ (commit d0184be13b4879e, also from Koen). I had to > modify the recipe to enable the define to actually get passed as a > compile option. For gstreamer-ti, there was no such hack in place, but > it was needed for the same reason. > > I would think it is a common requirement for recipes to include kernel > headers, and this warning has been around since 2.6.32. I got around it > with gstreamer-ti by installing the headers with headers_install into a > subdir of the headers directory set up currently by kernel.bbclass, and > pointing the gstreamer-ti recipe at that, but I'm not sure if there's a > better way. > > If there are some recipes that need internal kernel sources staged for > them, then it seems to me that we need both sets of kernel headers: one > exported to userspace (with headers_install) and one that is not. > Right? Can we agree on a standard place/manner for this? > > Below is my patch to get gstreamer-ti working, for illustration. I don't really have a better suggestion, apart from adding a var in e.g. bitbake.conf to point to the userspace stuff. We might even do the reverse, stage the full set into $kernel_dir/private and the userspace ones in $kernel_dir, that would make it more clear which recipes need internal API. regards, Koen > > -Michael > > From 71b3762ad5f6e7a8553a6b780296f7e994513f0b Mon Sep 17 00:00:00 2001 > From: Michael Jones <michael.jones@matrix-vision.de> > Date: Thu, 17 Mar 2011 17:23:53 +0100 > Subject: [PATCH] install kernel headers exported for userspace > > kernel.bbclass already copies and manipulates kernel headers into > sysroot, but it doesn't export them properly using "make headers_install" > which leads to a compiler error/warning in linux/types.h: > > "Attempt to use kernel headers from user space, see > http://kernelnewbies.org/KernelHeaders" > > --- > classes/kernel.bbclass | 5 +++++ > recipes/ti/gstreamer-ti.inc | 2 +- > 2 files changed, 6 insertions(+), 1 deletions(-) > > diff --git a/classes/kernel.bbclass b/classes/kernel.bbclass > index 422bcd7..6b46d51 100644 > --- a/classes/kernel.bbclass > +++ b/classes/kernel.bbclass > @@ -210,6 +210,11 @@ sysroot_stage_all_append() { > [ -e Module.symvers ] && install -m 0644 Module.symvers $kerneldir/ > > cp -fR scripts $kerneldir/ > + > + # install kernel headers in the proper manner to export them > + # for userspace programs > + userspace_hdrs=${kerneldir}/userspace > + oe_runmake headers_install INSTALL_HDR_PATH=${userspace_hdrs} ARCH=${ARCH} > } > > kernel_do_configure() { > diff --git a/recipes/ti/gstreamer-ti.inc b/recipes/ti/gstreamer-ti.inc > index 905e192..04d990f 100644 > --- a/recipes/ti/gstreamer-ti.inc > +++ b/recipes/ti/gstreamer-ti.inc > @@ -72,7 +72,7 @@ CPPFLAGS_append = " -DPlatform_${PLATFORM}" > export ENCODE_COMBO = "${installdir}/ti-codecs-server/encodeCombo.x64P" > export DECODE_COMBO = "${installdir}/ti-codecs-server/decodeCombo.x64P" > # Makefile also expects to be able to find the kernel headers from the envirionment > -export LINUXKERNEL_INSTALL_DIR = "${STAGING_KERNEL_DIR}" > +export LINUXKERNEL_INSTALL_DIR = "${STAGING_KERNEL_DIR}/userspace" > > do_configure_prepend() { > # PSP kernel is based on older DSS. we need to replace linux/omapfb.h with mach/omapfb.h > -- > 1.7.4.1 > > > MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler > Registergericht: Amtsgericht Stuttgart, HRB 271090 > Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: staging & using kernel headers 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 0 siblings, 1 reply; 9+ messages in thread From: Richard Purdie @ 2011-03-25 13:38 UTC (permalink / raw) To: Patches and discussions about the oe-core layer Cc: Michael Jones, openembedded-devel On Fri, 2011-03-18 at 10:55 +0100, Koen Kooi wrote: > CC:ing oe-core since we have kernel.bbclass patches there as well. > > Op 18 mrt 2011, om 10:49 heeft Michael Jones het volgende geschreven: > > > Hello Koen & co., > > > > I recently bumped into a problem with recipes ti-dmai and gstreamer-ti > > when they included the kernel headers. These headers were staged by > > kernel.bbclass sysroot_stage_all_append() with a lot of manual copying > > and manipulating links and such, rather than using 'oe_runmake > > headers_install'. Back in October Koen explained this > > (http://article.gmane.org/gmane.comp.handhelds.openembedded/37772) is > > because some recipes use private kernel API. The result of this with my > > 2.6.38 kernel > > DMAI and gst-ti don't really work with anything newer than 2.6.32-psp, we're trying to get that addressed internally. > > > is that I get a warning-turned-error from linux/types.h > > that "Attempt to use kernel headers from user space". > > > > ti-dmai_svn.bb hacks this (self-admittedly) by defining > > _EXPORTED_HEADERS_ (commit d0184be13b4879e, also from Koen). I had to > > modify the recipe to enable the define to actually get passed as a > > compile option. For gstreamer-ti, there was no such hack in place, but > > it was needed for the same reason. > > > > I would think it is a common requirement for recipes to include kernel > > headers, and this warning has been around since 2.6.32. I got around it > > with gstreamer-ti by installing the headers with headers_install into a > > subdir of the headers directory set up currently by kernel.bbclass, and > > pointing the gstreamer-ti recipe at that, but I'm not sure if there's a > > better way. > > > > If there are some recipes that need internal kernel sources staged for > > them, then it seems to me that we need both sets of kernel headers: one > > exported to userspace (with headers_install) and one that is not. > > Right? Can we agree on a standard place/manner for this? > > > > Below is my patch to get gstreamer-ti working, for illustration. > > I don't really have a better suggestion, apart from adding a var in e.g. bitbake.conf to point to the userspace stuff. > > We might even do the reverse, stage the full set into > $kernel_dir/private and the userspace ones in $kernel_dir, that would > make it more clear which recipes need internal API. Anything using internal kernel headers is effectively kernel module like and should be using STAGING_DIR_KERNEL. There should be a complete set of headers available there, particularly after recent improvemnents to kernel.bbclass in oecore. Note that using kernel headers like this effectively makes the package machine specific since the kernel is machine specific. Cheers, Richard ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: staging & using kernel headers 2011-03-25 13:38 ` Richard Purdie @ 2011-03-25 14:14 ` Michael Jones 2011-03-25 14:55 ` Richard Purdie 0 siblings, 1 reply; 9+ messages in thread From: Michael Jones @ 2011-03-25 14:14 UTC (permalink / raw) To: Richard Purdie Cc: openembedded-devel, Patches and discussions about the oe-core layer Hi Richard, On 03/25/2011 02:38 PM, Richard Purdie wrote: > On Fri, 2011-03-18 at 10:55 +0100, Koen Kooi wrote: >> CC:ing oe-core since we have kernel.bbclass patches there as well. >> >> Op 18 mrt 2011, om 10:49 heeft Michael Jones het volgende geschreven: >> >>> Hello Koen & co., >>> >>> I recently bumped into a problem with recipes ti-dmai and gstreamer-ti >>> when they included the kernel headers. These headers were staged by >>> kernel.bbclass sysroot_stage_all_append() with a lot of manual copying >>> and manipulating links and such, rather than using 'oe_runmake >>> headers_install'. Back in October Koen explained this >>> (http://article.gmane.org/gmane.comp.handhelds.openembedded/37772) is >>> because some recipes use private kernel API. The result of this with my >>> 2.6.38 kernel >> >> DMAI and gst-ti don't really work with anything newer than 2.6.32-psp, we're trying to get that addressed internally. >> >>> is that I get a warning-turned-error from linux/types.h >>> that "Attempt to use kernel headers from user space". >>> >>> ti-dmai_svn.bb hacks this (self-admittedly) by defining >>> _EXPORTED_HEADERS_ (commit d0184be13b4879e, also from Koen). I had to >>> modify the recipe to enable the define to actually get passed as a >>> compile option. For gstreamer-ti, there was no such hack in place, but >>> it was needed for the same reason. >>> >>> I would think it is a common requirement for recipes to include kernel >>> headers, and this warning has been around since 2.6.32. I got around it >>> with gstreamer-ti by installing the headers with headers_install into a >>> subdir of the headers directory set up currently by kernel.bbclass, and >>> pointing the gstreamer-ti recipe at that, but I'm not sure if there's a >>> better way. >>> >>> If there are some recipes that need internal kernel sources staged for >>> them, then it seems to me that we need both sets of kernel headers: one >>> exported to userspace (with headers_install) and one that is not. >>> Right? Can we agree on a standard place/manner for this? >>> >>> Below is my patch to get gstreamer-ti working, for illustration. >> >> I don't really have a better suggestion, apart from adding a var in e.g. bitbake.conf to point to the userspace stuff. >> >> We might even do the reverse, stage the full set into >> $kernel_dir/private and the userspace ones in $kernel_dir, that would >> make it more clear which recipes need internal API. > > Anything using internal kernel headers is effectively kernel module like > and should be using STAGING_DIR_KERNEL. There should be a complete set > of headers available there, particularly after recent improvements to > kernel.bbclass in oecore. Note that using kernel headers like this > effectively makes the package machine specific since the kernel is > machine specific. When you say "_internal_ kernel headers", I assume you mean kernel headers which aren't intended for user space. But because of the "Attempt to use kernel headers from user space" warning (or rather the motivations behind the warning), I don't want to/ I can't use the exact same headers for building apps which need public kernel API as I do for building modules which use internal kernel headers. > > Cheers, > > Richard > -Michael MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: staging & using kernel headers 2011-03-25 14:14 ` Michael Jones @ 2011-03-25 14:55 ` Richard Purdie 2011-03-25 16:02 ` Michael Jones 0 siblings, 1 reply; 9+ messages in thread From: Richard Purdie @ 2011-03-25 14:55 UTC (permalink / raw) To: Michael Jones Cc: openembedded-devel, Patches and discussions about the oe-core layer On Fri, 2011-03-25 at 15:14 +0100, Michael Jones wrote: > On 03/25/2011 02:38 PM, Richard Purdie wrote: > > On Fri, 2011-03-18 at 10:55 +0100, Koen Kooi wrote: > >> CC:ing oe-core since we have kernel.bbclass patches there as well. > >> > >> Op 18 mrt 2011, om 10:49 heeft Michael Jones het volgende geschreven: > >> > >>> Hello Koen & co., > >>> > >>> I recently bumped into a problem with recipes ti-dmai and gstreamer-ti > >>> when they included the kernel headers. These headers were staged by > >>> kernel.bbclass sysroot_stage_all_append() with a lot of manual copying > >>> and manipulating links and such, rather than using 'oe_runmake > >>> headers_install'. Back in October Koen explained this > >>> (http://article.gmane.org/gmane.comp.handhelds.openembedded/37772) is > >>> because some recipes use private kernel API. The result of this with my > >>> 2.6.38 kernel > >> > >> DMAI and gst-ti don't really work with anything newer than 2.6.32-psp, we're trying to get that addressed internally. > >> > >>> is that I get a warning-turned-error from linux/types.h > >>> that "Attempt to use kernel headers from user space". > >>> > >>> ti-dmai_svn.bb hacks this (self-admittedly) by defining > >>> _EXPORTED_HEADERS_ (commit d0184be13b4879e, also from Koen). I had to > >>> modify the recipe to enable the define to actually get passed as a > >>> compile option. For gstreamer-ti, there was no such hack in place, but > >>> it was needed for the same reason. > >>> > >>> I would think it is a common requirement for recipes to include kernel > >>> headers, and this warning has been around since 2.6.32. I got around it > >>> with gstreamer-ti by installing the headers with headers_install into a > >>> subdir of the headers directory set up currently by kernel.bbclass, and > >>> pointing the gstreamer-ti recipe at that, but I'm not sure if there's a > >>> better way. > >>> > >>> If there are some recipes that need internal kernel sources staged for > >>> them, then it seems to me that we need both sets of kernel headers: one > >>> exported to userspace (with headers_install) and one that is not. > >>> Right? Can we agree on a standard place/manner for this? > >>> > >>> Below is my patch to get gstreamer-ti working, for illustration. > >> > >> I don't really have a better suggestion, apart from adding a var in e.g. bitbake.conf to point to the userspace stuff. > >> > >> We might even do the reverse, stage the full set into > >> $kernel_dir/private and the userspace ones in $kernel_dir, that would > >> make it more clear which recipes need internal API. > > > > Anything using internal kernel headers is effectively kernel module like > > and should be using STAGING_DIR_KERNEL. There should be a complete set > > of headers available there, particularly after recent improvements to > > kernel.bbclass in oecore. Note that using kernel headers like this > > effectively makes the package machine specific since the kernel is > > machine specific. > > When you say "_internal_ kernel headers", I assume you mean kernel > headers which aren't intended for user space. But because of the > "Attempt to use kernel headers from user space" warning (or rather the > motivations behind the warning), I don't want to/ I can't use the exact > same headers for building apps which need public kernel API as I do for > building modules which use internal kernel headers. 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. 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. Cheers, Richard ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: staging & using kernel headers 2011-03-25 14:55 ` Richard Purdie @ 2011-03-25 16:02 ` Michael Jones 2011-03-28 12:42 ` [oe] " Richard Purdie 0 siblings, 1 reply; 9+ messages in thread From: Michael Jones @ 2011-03-25 16:02 UTC (permalink / raw) To: Richard Purdie Cc: koen, openembedded-devel, Patches and discussions about the oe-core layer On 03/25/2011 03:55 PM, Richard Purdie wrote: > On Fri, 2011-03-25 at 15:14 +0100, Michael Jones wrote: >> On 03/25/2011 02:38 PM, Richard Purdie wrote: >>> On Fri, 2011-03-18 at 10:55 +0100, Koen Kooi wrote: >>>> CC:ing oe-core since we have kernel.bbclass patches there as well. >>>> >>>> Op 18 mrt 2011, om 10:49 heeft Michael Jones het volgende geschreven: >>>> >>>>> Hello Koen & co., >>>>> >>>>> I recently bumped into a problem with recipes ti-dmai and gstreamer-ti >>>>> when they included the kernel headers. These headers were staged by >>>>> kernel.bbclass sysroot_stage_all_append() with a lot of manual copying >>>>> and manipulating links and such, rather than using 'oe_runmake >>>>> headers_install'. Back in October Koen explained this >>>>> (http://article.gmane.org/gmane.comp.handhelds.openembedded/37772) is >>>>> because some recipes use private kernel API. The result of this with my >>>>> 2.6.38 kernel >>>> >>>> DMAI and gst-ti don't really work with anything newer than 2.6.32-psp, we're trying to get that addressed internally. >>>> >>>>> is that I get a warning-turned-error from linux/types.h >>>>> that "Attempt to use kernel headers from user space". >>>>> >>>>> ti-dmai_svn.bb hacks this (self-admittedly) by defining >>>>> _EXPORTED_HEADERS_ (commit d0184be13b4879e, also from Koen). I had to >>>>> modify the recipe to enable the define to actually get passed as a >>>>> compile option. For gstreamer-ti, there was no such hack in place, but >>>>> it was needed for the same reason. >>>>> >>>>> I would think it is a common requirement for recipes to include kernel >>>>> headers, and this warning has been around since 2.6.32. I got around it >>>>> with gstreamer-ti by installing the headers with headers_install into a >>>>> subdir of the headers directory set up currently by kernel.bbclass, and >>>>> pointing the gstreamer-ti recipe at that, but I'm not sure if there's a >>>>> better way. >>>>> >>>>> If there are some recipes that need internal kernel sources staged for >>>>> them, then it seems to me that we need both sets of kernel headers: one >>>>> exported to userspace (with headers_install) and one that is not. >>>>> Right? Can we agree on a standard place/manner for this? >>>>> >>>>> Below is my patch to get gstreamer-ti working, for illustration. >>>> >>>> I don't really have a better suggestion, apart from adding a var in e.g. bitbake.conf to point to the userspace stuff. >>>> >>>> We might even do the reverse, stage the full set into >>>> $kernel_dir/private and the userspace ones in $kernel_dir, that would >>>> make it more clear which recipes need internal API. >>> >>> Anything using internal kernel headers is effectively kernel module like >>> and should be using STAGING_DIR_KERNEL. There should be a complete set >>> of headers available there, particularly after recent improvements to >>> kernel.bbclass in oecore. Note that using kernel headers like this >>> effectively makes the package machine specific since the kernel is >>> machine specific. >> >> When you say "_internal_ kernel headers", I assume you mean kernel >> headers which aren't intended for user space. But because of the >> "Attempt to use kernel headers from user space" warning (or rather the >> motivations behind the warning), I don't want to/ I can't use the exact >> same headers for building apps which need public kernel API as I do for >> building modules which use internal kernel headers. > > 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. > > 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. 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? thanks for the discussion, Michael > > Cheers, > > Richard > MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [oe] staging & using kernel headers 2011-03-25 16:02 ` Michael Jones @ 2011-03-28 12:42 ` Richard Purdie 2011-03-28 16:39 ` Khem Raj 2011-04-06 15:47 ` Michael Jones 0 siblings, 2 replies; 9+ messages in thread From: Richard Purdie @ 2011-03-28 12:42 UTC (permalink / raw) To: openembedded-devel; +Cc: koen, Patches, layer 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. > 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [oe] staging & using kernel headers 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 1 sibling, 1 reply; 9+ messages in thread From: Khem Raj @ 2011-03-28 16:39 UTC (permalink / raw) To: openembedded-devel; +Cc: koen, openembedded-core On Mon, Mar 28, 2011 at 5:42 AM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote: > >> 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. > If you use newer kernel should work ok why is that a problem ? kernel syscalls are backward compatible and we use oldest kernel version of like 2.6.16 for eglibc to build against so it should not be a problem to use different versions for kernel and kernel-headers. I think your problem lies elsewhere ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [oe] staging & using kernel headers 2011-03-28 16:39 ` Khem Raj @ 2011-04-07 13:03 ` Michael Jones 0 siblings, 0 replies; 9+ messages in thread From: Michael Jones @ 2011-04-07 13:03 UTC (permalink / raw) To: openembedded-devel; +Cc: koen, openembedded-core On 03/28/2011 06:39 PM, Khem Raj wrote: > On Mon, Mar 28, 2011 at 5:42 AM, Richard Purdie > <richard.purdie@linuxfoundation.org> wrote: >> >>> 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. >> > > If you use newer kernel should work ok why is that a problem ? kernel > syscalls are backward compatible > and we use oldest kernel version of like 2.6.16 for eglibc to build > against so it should not be a problem > to use different versions for kernel and kernel-headers. I think your > problem lies elsewhere > There is a kernel interface in the V4L2 development tree that is being introduced in 2.6.39 (but which in my local branch is patched on top of 2.6.38). The problem I kicked off this thread with was due to ti-dmai and gstreamer-ti _directly_ using the headers from this kernel, which since 2.6.32 gives a warning for doing so. Of course, I'm using the newer kernel for a reason, which is to use the new kernel API. So I need to use the headers from my local development kernel (built by an OE recipe) when building that application, which I'm now writing the recipe for. I thought at first that userspace apps were automatically built against the headers derived from the kernel being used (which is what the ti recipes do, but incorrectly). During this thread I realized that linux-libc-headers is a separate recipe intended for supplying user headers. I suppose I will use the method for my V4L2 app that I kicked off this thread with- staging the development kernel's headers with make_install somewhere which can be used by my app. As Richard pointed out earlier in this thread, making the package dependent on the kernel makes the package machine dependent. This is OK for this package, but I still want all other apps to be Angstrom-generic apps, so I don't want to change linux-libc-headers to use my kernel headers after all. MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [oe] staging & using kernel headers 2011-03-28 12:42 ` [oe] " Richard Purdie 2011-03-28 16:39 ` Khem Raj @ 2011-04-06 15:47 ` Michael Jones 1 sibling, 0 replies; 9+ messages in thread From: Michael Jones @ 2011-04-06 15:47 UTC (permalink / raw) To: openembedded-devel; +Cc: koen, openembedded-core 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2011-04-07 13:05 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[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 is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox