I'm using a Yocto-based SDK, produced by:
bitbake meta-toolchain-sdk
This creates the file
poky-eglibc-x86_64-arm-toolchain-gmae-1.3.sh
in the directory
build/tmp/deploy/sdk
I ran the installation script to install the SDK on my build system. Within the
SDK installation directory, under "sysroots", I have the following two
directories:
armv7a-vfp-neon-poky-linux-gnueabi
x86_64-pokysdk-linux
Unless I'm mistaken, the first one reflects the target environment, and the
second one contains what I need to do cross-compilation. Thus, the latter
contains the cross-compilation tools, and that's the sysroot to which all my
builds are directed.
I'm compiling the lm_sensors package for my target. As part of its work, it
tries to discover the version of the target linux kernel. To do this, it
compiles a very small file (etc/config.c) that includes the header file
<linux/kernel.h>.
As it happens, <linux/kernel.h> does *not* appear in the cross-compilation
sysroot, so this simple task fails. That header file *does* appear in the
target sysroot, but that's of no use to me in the cross-compilation process.
I believe one of the following is true:
1) The lm_sensors package is doing something entirely legitimate, and the file
<linux/kernel.h> *should* appear in the cross-compilation sysroot to support
this. The Yocto SDK build target needs a small fix so that <linux/kernel.h> is
properly added to the cross-compilation sys root. In the meantime, I can work
around this oversight by creating a symbolic link.
2) I've made a mistake in setting up my build environment because I don't
understand how cross-compilation *should* be done. If done properly, the
cross-compilation process will have access to *both* sysroots and get what it
needs from each. If this is the case, please tell me what I appear to have done
wrong.
3) Something else.
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
