[yocto] Inconsistency in the SDK

[Khem Raj]

Did you source the env script before doing all that ?

On Wednesday, January 23, 2013, Patrick Turley <PatrickTurley at gamestop.com>
wrote:
> 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 at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20130123/93027678/attachment.html>