On Mon, Aug 20, 2012 at 11:45 AM, Khem Raj <raj.k...@gmail.com> wrote: > On Mon, Aug 20, 2012 at 12:23 AM, David Nyström <david.nyst...@enea.com> > wrote: >> On 08/14/2012 09:26 PM, Khem Raj wrote: >>> >>> On Tue, Aug 14, 2012 at 12:49 AM, David Nyström <david.nyst...@enea.com> >>> wrote: >>>> >>>> Hi, it looks like this was merged to the denzil branch, and >>>> PREFERRED_PROVIDER_linux-libc-headers-nativesdk was moved back to >>>> distro.conf. >>>> Any reason for this ? >>> >>> why do you want nativesdk headers to come from BSP its a fsl-ppc bsp I >>> dont expect it to have something special for SDK hosts which are >>> usually x86 ? afterall these are for >>> the SDK host and not for target. Moreover it means that this BSP will >>> not play in the multi BSP environment something you never want. >> >> >> My main concern is that meta-toolchain uses linux-libc-headers-nativesdk for >> the meta-toolchain >> tarball build, i.e. the meta-toolchain API may differ from the on-target API >> in regards to kernel-headers, no ? >> >> This might very well be true if kernel version of >> linux-libc-headers-nativesdk != linux-libc-headers > > whats the point of keeping header versions same across two entirely > different systems. > can you point to some instances where this API difference if any is in > conflict ?
I just checked and we do have a few obscure bits in our kernel tree's header files. Nothing that 99.9% would use but it seems reasonable to include these... -M _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
