How is Linaro tool chain deployement?

I have a doubt regarding the development setup.
I have build open embedded images and sdks and deployed successfully in my development machine.
Not yet used the sdk, but bitbaked successfully and images and sdks and deployed using the .sh script of sdk.
I have downloaded pre-built images from toradex links and the linaro tool chain as directed by the toradex how to pages.
But my confusion is that in case of linaro we are not running any .sh files. So just the extraction of archive is ok for that? Or I am missing some thing here?


You are mixing stuff here:

Linaro provides binary installers for their flavour of the toolchain. This is provided in a tar archive which can be extracted anywhere on your build machine.
It is your responsibility to set the environment so that the toolchain can be used, e.g. for U-Boot and Kernel development you set the environment as follows:

export ARCH=arm
export PATH=~/gcc-linaro/bin/:$PATH
export CROSS_COMPILE=arm-linux-gnueabihf-

If you compile your user space applications you will have to make sure that the cross compiler is used by whatever means, e.g. using above environment variables in your make file.

Additionally you might want to link against libraries installed in the rootfs of your target. The standalone toolchain from Linaro does not include any files needed for doing so (headers/pkgconfig data/libs) apart from the gcc and glibc libraries. So you will need to provide those files by yourself.

On the other hand if you use an SDK build from the openembedded meta data you will not only get a toolchain built by bitbake which can be used in place of the Linaro binary toolchain as explained above but you get additionally a target sysroot which contains all developer files. This SDK gets packaged into a shell script which basically is a self extracting archive.

The script you mention (/usr/local/oecore-x86_64/environment-setup-armv7at2hf-neon-angstrom-linux-gnueabi) eases the use of this toolchain and the target sysroot. It sets a bunch of environment variables so that make files can pick up the cross toolchain, headers from the target sysroot and the libraries.


Thank you very much for clarifying that. Things are clearer now.
Actually I believe I have succeeded the open embedded build process at least for the non.qt applications. I have compiled the hello world through your how to pages.
I tried linaro method to understand the overall working mechanism of the process. The command line example area of the how to pages is not having linaro method. But now I have found that in the eclipse page I think. I will try that.
So as you said since the target image is not linaro responsibility, I think the pre-image you provide can supply the target files. I think I can find it in the eclipse example I am about to try.
Thanks for the response.
btw I think there is a slight inconsistency in the how to page please see below

here the compile method is shown like below

export CROSS_COMPILE=~/oe-core/build/out-glibc/sysroots/x86_64-linux/usr/bin/arm-angstrom-linux-gnueabi/arm-angstrom-linux-gnueabi-
${CROSS_COMPILE}gcc --sysroot=${HOME}/oe-core/build/out-glibc/sysroots/apalis-t30 -mfloat-abi=hard -o hello_world hello_world.c

But in my oe-core folder the naming is slightly different
/oe-core/build/out-glibc/sysroots in my case is /oe-core/build/tmp-glibc/sysroots

I have followed the open embedded core page, but the version I have installed, I am not able to find for your reference.
This caused my cross compile to fail. I am not sure weather this is any version issue I might have overlooked.
I am just mentioning it in case it is usefull for correction. But I am not sure to specify my version info etc.
I think thist is a comment but I have posted as an answer. just now noticed. dont now how to revert. Sorry for that.
Thanks and Regards

Thanks for reporting this.

The path name depends on the BSP version. The move from out-glibc to tmp-glibc happend around BSP version V2.6.1.

I created an internal ticket to go through the developer web page and clean up some of this.