[linux-yocto] Difference in sysroots and work linux include file

[Bruce Ashfield]

On 14-04-08 03:27 AM, Sathish Kumar Balasubramaniam -ERS, HCL Tech wrote:
> Thanks Bruce :)
>
> I added the following to the bbappend file and it got compiled.
> CPPFLAGS = " -I${STAGING_KERNEL_DIR}/include"
>
> However I received the following warning message in the log.do_compile file
>
> build/tmp/sysroots/<machine>/usr/src/kernel/include/linux/types.h:13:2: warning: #warning "Attempt to use kernel headers from user space, see http://kernelnewbies.org/KernelHeaders" [-Wcpp]
>
> Hope it's not an issue for this case.

For your case, it should be fine, the header warning is telling you
that you are including them without KERNEL being defined, which
technically can be a problem since the modern kernel wants those
sanitized headers to be available.

The alternative to the libc-headers (which are sanitized) and the
STAGING_KERNEL_DIR (which is not uapi sanitized) would be to install
your specific kernel's uapi headers into another directory in the
sysroot and have your package use that include path.

That export can be done in a few ways, one of which is bbappending the
kernel recipe in a layer, and creating a do_install_append() function
which exports the headers, i.e. something like the untested:

do_install_append() {
     make headers_install INSTALL_HDR_PATH="${D}/usr/my-headers"
}

sysroot_stage_all_append() {
         sysroot_stage_dir "${D}/usr/my-headers" 
"${SYSROOT_DESTDIR}/usr/my-headers"
}

And you'd then use -I=/usr/myheaders/include to reference the sysroot
copy of those headers.


But if what you have is working at runtime, keeping it simple might
be a good idea as well :)

Cheers,

Bruce

>
>
> Regards,
> B.Sathish Kumar
>
> -----Original Message-----
> From: Bruce Ashfield [mailto:bruce.ashfield at windriver.com]
> Sent: Monday, April 07, 2014 7:42 PM
> To: Sathish Kumar Balasubramaniam -ERS, HCL Tech; linux-yocto at yoctoproject.org
> Subject: Re: [linux-yocto] Difference in sysroots and work linux include file
>
> On 14-04-07 08:10 AM, Sathish Kumar Balasubramaniam -ERS, HCL Tech wrote:
>> I am using Dora version of Yocto with my BSP.
>>
>> There is a compilation issue and the cause is certain values
>> (V4L2_MBUS_FMT_ARGB8888_1X32  and V4L2_MBUS_FMT_AYUV8_1X32) not
>> defined in the following file
>>
>> build/tmp/sysroots/<machine>/usr/include/linux/v4l2-mediabus.h
>>
>> which is needed by media-ctl's v4l2subdev.c file.
>>
>> There are 3 different versions of this file
>>
>> 1.
>> build/tmp/sysroots/<machine>/usr/include/linux/v4l2-mediabus.h
>>                   - needed values not present. Include path set to this
>> for compilation of media-ctl
>
> This is the linux-libc-headers header file. They are sanitized and based off a given kernel's pristine source. This is for the toolchain
> (glibc) and all applications in the system using those interfaces.
>
>>
>> 2.
>> build/tmp/sysroots/<machine>/usr/src/kernel/include/linux/v4l2-mediabus.h
>>                   - needed values present. Same as (3) file
>>
>> 3.
>> build/tmp/work/<machine>-poky-linux-gnueabi/linux-yocto/3.4+git<srcrev>/git/include/linux/v4l2-mediabus.h
>>                   - needed values present. Same as (2) file
>
> #2 and #3 are the actual kernel sources in the sysroot. They contain changes that have been patched into the files.
>
>>
>> My doubt is why the above files are different ? why the (1) file is
>> not the same (2) or (3) ? which yocto config is creating this ?
>
> See above. #1 is NOT supposed to match #2 and #3, it is part of the toolchain and stays consistent over time.
>
> Patching the kernel and exporting it over these headers is incorrect and has been discussed on the mailing lists many times. Richard has a warning and explanation in the libc-headers.inc file:
>
> #########################################################################
> ####                        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 machine specific C library. This does mean your # recipe needs a DEPENDS += "virtual/kernel" but again, that is fine and # makes total sense.
> #
> # There can also be a case where your kernel extremely old and you want # an older libc ABI for that old kernel. The headers installed by this # recipe should still be a standard mainline kernel, not your own custom # one.
> #
> # -- RP
>
>
>
>>
>> I though the (3) file should have been copied to (1) and (2). Looks
>> its different.
>>
>> For my problem, either I need to change the compilation include path
>> (where I need to change ?) or fix this difference issue (how ?)
>
> Your application needs to look in the STAGING_KERNEL_DIR structure (#2 and #3 in your list) for the header file.
>
> Cheers,
>
> Bruce
>
>>
>> Anyone has any faced this issue before ?
>>
>> Regards,
>>
>> B.Sathish Kumar
>>
>>
>>
>> ::DISCLAIMER::
>> ----------------------------------------------------------------------
>> ----------------------------------------------------------------------
>> --------
>>
>> The contents of this e-mail and any attachment(s) are confidential and
>> intended for the named recipient(s) only.
>> E-mail transmission is not guaranteed to be secure or error-free as
>> information could be intercepted, corrupted, lost, destroyed, arrive
>> late or incomplete, or may contain viruses in transmission. The e mail
>> and its contents (with or without referred errors) shall therefore not
>> attach any liability on the originator or HCL or its affiliates.
>> Views or opinions, if any, presented in this email are solely those of
>> the author and may not necessarily reflect the views or opinions of
>> HCL or its affiliates. Any form of reproduction, dissemination,
>> copying, disclosure, modification, distribution and / or publication
>> of this message without the prior written consent of authorized
>> representative of HCL is strictly prohibited. If you have received
>> this email in error please delete it and notify the sender
>> immediately.
>> Before opening any email and/or attachments, please check them for
>> viruses and other defects.
>>
>> ----------------------------------------------------------------------
>> ----------------------------------------------------------------------
>> --------
>>
>>
>>
>