$ bitbake -c populate_sdk core-image-minimal $ cd tmp/deploy/sdk $ ./poky-eglibc-x86_64-core-image-minimal-armv5te-toolchain-1.6+snapshot.sh Enter target directory for SDK (default: /opt/poky/1.6+snapshot): /opt/poky/alternative1.6 You are about to install the SDK to "/opt/poky/alternative1.6". Proceed[Y/n]?Y [sudo] password for [sudo_user]: Extracting SDK...done Setting it up...done SDK has been successfully set up and is ready to be used. At this moment cross-gcc still reference the default directory /opt/poky/1.6+snapshot and cannot be properly used. Another issue is that there are reference to the build sysroot directory which I think does not make sense. $ cd /opt/poky/alternative1.6/sysroots/x86_64-pokysdk-linux $ ./usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-gcc -v Using built-in specs. COLLECT_GCC=./usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-gcc COLLECT_LTO_WRAPPER=/opt/poky/alternative1.6/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/../../libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.8.2/lto-wrapper Target: arm-poky-linux-gnueabi Configured with: /media/sdd1/fb/tufl/linux/yoctoproject2/poky/build_quemuarm/tmp/work-shared/gcc-4.8.2-r0/gcc-4.8.2/configure --build=x86_64-linux --host=x86_64-pokysdk-linux --target=arm-poky-linux-gnueabi --prefix=/opt/poky/1.6+snapshot/sysroots/x86_64-pokysdk-linux/usr --exec_prefix=/opt/poky/1.6+snapshot/sysroots/x86_64-pokysdk-linux/usr --bindir=/opt/poky/1.6+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi --sbindir=/opt/poky/1.6+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi --libexecdir=/opt/poky/1.6+snapshot/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi --datadir=/opt/poky/1.6+snapshot/sysroots/x86_64-pokysdk-linux/usr/share --sysconfdir=/opt/poky/1.6+snapshot/sysroots/x86_64-pokysdk-linux/etc --sharedstatedir=/opt/poky/1.6+snapshot/sysroots/x86_64-pokysdk-linux/com --localstatedir=/opt/poky/1.6+snapshot/sysroots/x86_64-pokysdk-linux/var --libdir=/opt/poky/1.6+snapshot/sysroots/x86_64-pokysdk-linux/usr/lib/arm-poky-linux-gnueabi --includedir=/opt/poky/1.6+snapshot/sysroots/x86_64-pokysdk-linux/usr/include --oldincludedir=/opt/poky/1.6+snapshot/sysroots/x86_64-pokysdk-linux/usr/include --infodir=/opt/poky/1.6+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/info --mandir=/opt/poky/1.6+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/man --disable-silent-rules --disable-dependency-tracking --with-libtool-sysroot=/media/sdd1/fb/tufl/linux/yoctoproject2/poky/build_quemuarm/tmp/sysroots/x86_64-nativesdk-pokysdk-linux --with-gnu-ld --enable-shared --enable-languages=c,c++ --enable-threads=posix --enable-multilib --enable-c99 --enable-long-long --enable-symvers=gnu --enable-libstdcxx-pch --program-prefix=arm-poky-linux-gnueabi- --without-local-prefix --enable-target-optspace --enable-lto --enable-libssp --disable-bootstrap --disable-libmudflap --with-system-zlib --with-linker-hash-style=gnu --enable-linker-build-id --with-ppl=no --with-cloog=no --enable-checking=release --enable-cheaders=c_global --with-gxx-include-dir=/opt/poky/1.6+snapshot/sysroots/armv5te-poky-linux-gnueabi/usr/include/c++ --with-build-time-tools=/media/sdd1/fb/tufl/linux/yoctoproject2/poky/build_quemuarm/tmp/sysroots/x86_64-linux/usr/arm-poky-linux-gnueabi/bin --with-sysroot=/opt/poky/1.6+snapshot/sysroots/armv5te-poky-linux-gnueabi --with-build-sysroot=/media/sdd1/fb/tufl/linux/yoctoproject2/poky/build_quemuarm/tmp/sysroots/qemuarm --disable-libunwind-exceptions --disable-libssp --disable-libgomp --disable-libmudflap --with-mpfr=/media/sdd1/fb/tufl/linux/yoctoproject2/poky/build_quemuarm/tmp/sysroots/x86_64-nativesdk-pokysdk-linux --with-mpc=/media/sdd1/fb/tufl/linux/yoctoproject2/poky/build_quemuarm/tmp/sysroots/x86_64-nativesdk-pokysdk-linux --enable-nls Thread model: posix gcc version 4.8.2 (GCC) Similar issue occurs with bitbake meta-toolchain
What do you mean by "cannot be properly used"? Did you source the environment setup script and the compilation failed? gcc -v will always show how the configure script was called. Unfortunately, the relocation script cannot change those paths... For binaries, other than the dynamic loader itself, only the path to the dynamic loader is changed. Can you provide more info regarding what exactly fails?
I'm waiting for more info on this.
Its expected that people use the toolchain through the environment script which passed the --sysroot= flag to the compiler and toolchain. It is not expected that the relocation script changes the default spec entries. This is therefore not a bug as far as I can tell.
Sorry for late feedback on this. It is indeed not a bug. The intent was to deploy the toolchain on a nfs location (in order to be used on many build machine). The issue I encountered turned out to be caused by the nfs and not the toolchain (deployment) itself. e.g: [user@machine ~]$ readlink -f . /nfs/hosts/nfsserver/homes/user [tufl@machine ~]$ pwd /homes/user
Verified as per Tudor's comment.