Re: [yocto] Inconsistency in the SDK
Did you source the env script before doing all that ? On Wednesday, January 23, 2013, Patrick Turley patricktur...@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@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Inconsistency in the SDK
On Jan 23, 2013, at 10:21 AM, Khem Raj raj.k...@gmail.commailto:raj.k...@gmail.com wrote: Did you source the env script before doing all that ? Thank you for your question, but it doesn't apply. All of this happens *before* I even tried to build anything. The fundamental problem is that the SDK installation script puts the native sysroot in one directory, but the tool chain believes the default location for the native sysroot is in a *different* directory that doesn't exist. On Wednesday, January 23, 2013, Patrick Turley patricktur...@gamestop.commailto:patricktur...@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@yoctoproject.orgmailto:yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Inconsistency in the SDK
On Jan 23, 2013, at 10:19 AM, Zhang, Jessica jessica.zh...@intel.com wrote: Please file a bug at bugzilla.yoctoproject.org Done: https://bugzilla.yoctoproject.org/show_bug.cgi?id=3784 Thank you. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Inconsistency in the SDK
On Wed, Jan 23, 2013 at 8:05 AM, Patrick Turley patricktur...@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 This will contain builds of machine specific packages Also, under tmp/sysroots, we see these two: dm8148-mpu This is machine sysroot which is not same as SDK sysroot dm8148-mpu-tcbootstrap intermediate sysroot needed for bootstrapping the build Finally, when I install the SDK, I see the following under sysroots: how did you generate and install the SDK ? dm8148_mpu-poky-linux-gnueabi x86_64-pokysdk-linux I am using 1.3/danny and I dont see this problem the first sysroot has MACHINE_ARCH and not MACHINE_NAME as first part of target triplet. The second sysroot is for nativesdk packages which is quite OK. so It would be interested to see what your local.conf and machine.conf looks like. 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 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
