Here's our machine in local.conf:
MACHINE = "dm8148-mpu"
Naturally, then, we see a directly like this under tmp/work:
dm8148_mpu-poky-linux-gnueabi
Also, under tmp/sysroots, we see these two:
dm8148-mpu
dm8148-mpu-tcbootstrap
Finally, when I install the SDK, I see the following under sysroots:
dm8148_mpu-poky-linux-gnueabi
x86_64-pokysdk-linux
However, if I ask the cross-compiler the path to its default sysroot, I see
this:
$ cd /opt/poky/1.3/sysroots/x86_64-pokysdk-linux
$ cd usr/bin/armv7a-vfp-neon-poky-linux-gnueabi
$ ./arm-poky-linux-gnueabi-gcc -print-sysroot
/opt/poky/1.3/sysroots/armv7a-vfp-neon-poky-linux-gnueabi
There is no such directory. That is, the default sysroot for the SDK doesn't
exist.
Now, if I go back and look in tmp/work, I realize that I see *both* of these:
dm8148_mpu-poky-linux-gnueabi
armv7a-vfp-neon-poky-linux-gnueabi
There are a number of work directories under both.
It seems to me there are these possibilities:
1) There are at least two different (and disagreeing) methods to compute the
architecture "tuple," and different pieces of the system are choosing different
methods. These different methods usually agree, but sometimes they don't. Thus,
when they *do* agree, it's "luck."
2) These strings *should* agree, but something is missing from our machine
definition that causes them to disagree (we weren't using our own machine
definition until recently). In that case, the machine definition code should
change such that it's not *possible* for these strings to disagree. Also, I'd
like to know what we missed, so we can fix it.
3) These strings, though similar, actually *mean* different things and are
*both* correct. The only problem is that the build process for the tool chain
chooses the wrong one when defining the default sysroot path.
In any case, I can fix the immediate problem with a symbolic link, but that's
not a long-term solution.
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
