Here's our machine in local.conf: MACHINE = "dm8148-mpu" Naturally, then, we see a directory 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 problem is either: a) The build process for the tool chain chooses the wrong one when defining the default sysroot path. b) The build process for SDK packaging chooses the wrong one when defining the installed sysroot path. In any case, I can fix the immediate problem with a symbolic link, but that's not a long-term solution.
Here is the e-mail thread that spawned this bug: https://lists.yoctoproject.org/pipermail/yocto/2013-January/013931.html
Patrick, This comment has two parts: 1. explains what might have happened in your setup and 2. explains why this is not really a bug ### 1: The SDKTARGETSYSROOT directory, which in your case is /opt/poky/1.3/sysroots/sysdm8148_mpu-poky-linux-gnueabi, is computed as follows: ${SDKPATH}/sysroots/${MULTIMACH_TARGET_SYS} which, expanded a little further, turns into ${SDKPATH}/sysroots/${PACKAGE_ARCH}${TARGET_VENDOR}-${TARGET_OS}. PACKAGE_ARCH is, according to documentation, "The architecture needed for using a resulting package. If you have machine-dependent configuration options in your bitbake file add a PACKAGE_ARCH = "${MACHINE_ARCH}" to the file." So, PACKAGE_ARCH should be, in your case, "armv7a-vfp-neon" unless you set PACKAGE_ARCH to be ${MACHINE_ARCH}. All the data provided above was extracted by running a "bitbake -e meta-toolchain". You can easily check how the variables were set in your setup too. I ran a test for MACHINE=beagleboard and PACKAGE_ARCH=armv7a-vfp-neon whereas MACHINE_ARCH=beagleboard. ### 2: On the other hand though, unless you want to run the toolchain binaries without providing the --sysroot option, I don't really understand why would you need the default gcc sysroot to match the actual target sysroot. What if you want to install the SDK in a different place than the default? The SDK is now relocatable. In this case the default sysroot will clearly not match with the actual target sysroot path. That's why, in the environment-setup script, the --sysroot option is added to the CC/CPP/CXX/LD variables which you can later use to compile your applications. I believe this issue can be closed.
Thank you for putting so much work into a well-considered and helpful comment. ### 1: I ran bitbake -e, as you did, against both meta-toolchain and our own SDK image. Here's what I found: $ bitbake -e meta-toolchain | grep 'MACHINE_ARCH=' # MACHINE_ARCH=${@[d.getVar('TUNE_PKGARCH', True), d.getVar('MACHINE', True)][bool(d.getVar('MACHINE', True))].replace('-', '_')} MACHINE_ARCH="dm8148_mpu" $ bitbake -e meta-toolchain | grep 'PACKAGE_ARCH=' # PACKAGE_ARCH=${TUNE_PKGARCH} PACKAGE_ARCH="armv7a-vfp-neon" $ bitbake -e spawnlabs-image-basic-sdk | grep 'MACHINE_ARCH=' # MACHINE_ARCH=${@[d.getVar('TUNE_PKGARCH', True), d.getVar('MACHINE', True)][bool(d.getVar('MACHINE', True))].replace('-', '_')} MACHINE_ARCH="dm8148_mpu" $ bitbake -e spawnlabs-image-basic-sdk | grep 'PACKAGE_ARCH=' # PACKAGE_ARCH=${MACHINE_ARCH} PACKAGE_ARCH="dm8148_mpu" You said the default tool chain path is contructed with this expression: ${SDKPATH}/sysroots/${PACKAGE_ARCH}${TARGET_VENDOR}-${TARGET_OS} That certainly does seem to be the case. ### 2: Running the toolchain without the "--sysroot" option is *precisely* why I want the *default* sysroot to match the *installed* sysroot. If everyone always used the "--sysroot" option, then then there would be no reason for a default at all. It's an important feature for many people, and it's an *essential* feature for me. In my case, I'm building some third-party code that has a twisted Make file structure and I prefer not to touch it. Specifically, I don't want to find every tool chain command line and insert "--sysroot". The best choice for me is to install the tool chain in the directory that matches the default path, and then everything just works. So, we have established that it's valuable for the default sysroot to match the installed sysroot. We have also established that, when PACKAGE_ARCH is set to MACHINE_ARCH, they will *not* match. As you described in #1, the OE/Yocto scripts seem to have a well-defined system for deciding where the target sysroot should be installed. Apparently, the choice that OE/Yocto makes isn't being communicated to the tool chain recipe when the executables are being built. That *should* be happening, and that's the bug.
Patrick, Thanks for filing this. It turns out that SDKTARGETSYSROOT should, actually, point to TUNE_PKGARCH not PACKAGE_ARCH. When, the cross-canadian toolchain is built, the default sysroot passed points to TUNE_PKGARCH. Also, all the setup scripts in the SDK directory set sysroot pointing to TUNE_PKGARCH. Sent a patch on the or-core ML. Give it a try and let me know. Now, your target sysroot directory will be armv7a-vfp-neon-poky-linux-gnueabi, not dm8148_mpu-poky-linux-gnueabi.
This is excellent news. You've reduced the entropy of Yocto measurably.
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=c723d1a38f35d5922eac113b6071748199742631