Hello William and Martin, On 10/12/2015 15:53, William Mills wrote: > > On 12/10/2015 09:40 AM, Vuille, Martin (Martin) wrote: >> Hi Valentin, >> >> When we first encountered the need for custom kernel headers, I asked >> a similar question to yours on this list. And what I learned from some of the >> responses was that modifying the standard headers was fraught with >> problems, including the issue that you raise. >> >> Fortunately, we got away without having to modify and export any standard >> headers, so I dodged that bullet. >> >> Some ideas that come to mind: >> >> - Can you install your customized version in ${includedir}/XXX and use the >> include path search order to make sure the compiler sees it first? > > This was the approach we used in a Debian based system. Applications > that needed to be dependent on the custom capabilities of our kernel > depended on our XXX-kernel-header package and adjusted their include > path to use it first. All other apps continue to use the standard > kernel headers. (busybox or tar does not really care about our new > wizbang feature and the Debian distro sure was not going to rebuild them > just for us.) > > I see no reason this could not work as well in an OE based distro. > >> >> - Can you include the standard header in a "wrapper" header and make your >> customizations in the wrapper instead? >> >> Regards, >> MV
I just wanted to thank you for your answers and suggestion. I have now used this approach and it works fine: - make a new package that installs our changed linux-headers into another directory than the linux-libc-headers - added this package to TOOLCHAIN_TARGET_TASK so that it gets installed to the SDK's sysroot - changed the include path of the userspace applications that require these changed headers and use the SDK so that they find them ($SDKTARGETSYSROOT helps a lot here). Valentin >> >>> -----Original Message----- >>> From: Longchamp, Valentin [mailto:valentin.longch...@keymile.com] >>> Sent: December 10, 2015 4:47 AM >>> To: Vuille, Martin (Martin); yocto@yoctoproject.org >>> Cc: Brunck, Holger >>> Subject: RE: Custom kernel headers and SDK >>> >>> Hi Martin, >>> >>> Thanks a lot for the suggestion. I had in the meantime come to a simliar >>> solution: define a linux-XXX-headers recipe in our own meta layer where I >>> install the missing kernel headers and then I add this linux-XXX-headers-dev >>> package to our SDK's sysroot thanks to TARGET_TOOLCHAIN_TASK. >>> Your implementation looks fine and I am going to pick some ideas from it. >>> >>> However, I have stumbled upon another problem with this approach: it >>> works well if you add new files to the kernel headers. We unforntunately >>> have at least one uapi file (i2c.h to name it) that is present in the >>> standard >>> kernel headers where we have our own version with some >>> additions/extensions. If I install our version from ou linux-XXX-headers >>> recipe, bitbake (correctly) complains that this file is provided by 2 >>> packages >>> (linux-libc-headers and linux-XXX-headers). And here I really don't know how >>> to solve this issue. Any ideas/suggestions ? >>> >>> Thanks >>> >>> Valentin -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto