SDK meta-toolchain
I'm a bit confused about what exactly meta-toolchain is building? It seems to be bitbaking gcc and creating a toolchain with the prefix x86_64-oesdk-linux- (default SDK_PREFIX) but I'm not sure what it is. Is it a cross-compile for my target MACHINE or a compiler for my build machine? Based on the prefix name I am assuming the latter.
Thanks for any help.
Kyle
Quoted 5 lines · Kyle Farnsworth
I'm a bit confused about what exactly meta-toolchain is building? It seems to be bitbaking gcc and creating a toolchain with the prefix x86_64-oesdk-linux- (default
SDK_PREFIX) but I'm not sure what it is. Is it a cross-compile for my target MACHINE or a compiler for my build machine? Based on the prefix name I am assuming the latter.
There are two ways to generate an SDK.
* targeted SDK -- This is a meta-toolchain* recipe that lists -exactly- what is going to be in the SDK. This is great if you want to limit your SDK to specific libraries for your application developers.
* implied / image based SDK -- This type of SDK bases off of what is in the image to generate an SDK that contains all of the libraries that are runnable inside of the image. This is a very simple way to generate an SDK for application developers that -will- match the run-time image.
Both of the above have their place, depending on the level of command and control people want.
The basic meta-toolchain is just the cross compile toolchain and I believe the libc. meta-toolchain-gmae is an example Gnome Mobile Application Environment.
--Mark
Quoted 8 lines
Thanks for any help.
Kyle_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Quoted 5 lines · Mark Hatle
There are two ways to generate an SDK.
* targeted SDK -- This is a meta-toolchain* recipe that lists -exactly- what is going to be in the SDK. This is great if you want to limit your SDK to specific libraries for your application developers.
Is this the one created using:
$ bitbake meta-toolchain
?
Quoted 4 lines
* implied / image based SDK -- This type of SDK bases off of what is in the image to generate an SDK that contains all of the libraries that are runnable inside of the image. This is a very simple way to generate an SDK for application developers that -will- match the run-time image.
Is this the one created by:
$ bitbake -c populate_sdk <image>
?
Quoted 18 lines · Trevor Woerner
Quoted 5 lines · Mark Hatle
There are two ways to generate an SDK.
* targeted SDK -- This is a meta-toolchain* recipe that lists -exactly- what is going to be in the SDK. This is great if you want to limit your SDK to specific libraries for your application developers.
Is this the one created using:
$ bitbake meta-toolchain?
Quoted 4 lines
* implied / image based SDK -- This type of SDK bases off of what is in the image to generate an SDK that contains all of the libraries that are runnable inside of the image. This is a very simple way to generate an SDK for application developers that -will- match the run-time image.
Quoted 6 lines
Is this the one created by:
$ bitbake -c populate_sdk <image>?
Yes to both questions.
--Mark
Quoted 19 lines · Mark Hatle
Quoted 5 lines · Kyle Farnsworth
I'm a bit confused about what exactly meta-toolchain is building? It seems to be bitbaking gcc and creating a toolchain with the prefix x86_64-oesdk-linux- (default
SDK_PREFIX) but I'm not sure what it is. Is it a cross-compile for my target MACHINE or a compiler for my build machine? Based on the prefix name I am assuming the latter.There are two ways to generate an SDK.
* targeted SDK -- This is a meta-toolchain* recipe that lists -exactly- what is going to be in the SDK. This is great if you want to limit your SDK to specific libraries for your application developers.
* implied / image based SDK -- This type of SDK bases off of what is in the image to generate an SDK that contains all of the libraries that are runnable inside of the image. This is a very simple way to generate an SDK for application developers that -will- match the run-time image.
Quoted 6 lines
Both of the above have their place, depending on the level of command and control people want.
The basic meta-toolchain is just the cross compile toolchain and I believe the libc. meta-toolchain-gmae is an example Gnome Mobile Application Environment.
Thanks. This a good info. I need to do the targeted SDK. But why is it re-creating the cross-compile toolchain with the new prefix and a libc? I also have cases where I want to deliver an external toolchain within the SDK.
Quoted 23 lines · Kyle Farnsworth
Quoted 22 lines · Mark Hatle
Quoted 5 lines · Kyle Farnsworth
I'm a bit confused about what exactly meta-toolchain is building? It seems to be bitbaking gcc and creating a toolchain with the prefix x86_64-oesdk-linux- (default
SDK_PREFIX) but I'm not sure what it is. Is it a cross-compile for my target MACHINE or a compiler for my build machine? Based on the prefix name I am assuming the latter.There are two ways to generate an SDK.
* targeted SDK -- This is a meta-toolchain* recipe that lists -exactly- what is going to be in the SDK. This is great if you want to limit your SDK to specific libraries for your application developers.
* implied / image based SDK -- This type of SDK bases off of what is in the image to generate an SDK that contains all of the libraries that are runnable inside of the image. This is a very simple way to generate an SDK for application developers that -will- match the run-time image.
Both of the above have their place, depending on the level of command and control people want.
Quoted 7 lines
Quoted 3 lines
The basic meta-toolchain is just the cross compile toolchain and I believe the libc. meta-toolchain-gmae is an example Gnome Mobile Application Environment.
Thanks. This a good info. I need to do the targeted SDK. But why is it re-creating the cross-compile toolchain with the new prefix and a libc? I also have cases where I want to deliver an external toolchain within the SDK.
There are three types of packages in oe-core.
- Target -- runs on the target
- native -- runs on the host (variant called 'cross')
- nativesdk -- runs on the 'sdkhost' (variant called 'crosssdk')
The SDK allows you to build SDK software for a host that is different then your build host. Also the nativesdk is 'glibc' independent, while the native version is specific to your host. This allows the SDK to be shared with other developers.
--Mark
Quoted 8 lines
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Quoted 1 line · Mark Hatle
- nativesdk -- runs on the 'sdkhost' (variant called 'crosssdk')
Is this related to the SDKMACHINE setting?
Quoted 5 lines · Trevor Woerner
Quoted 1 line · Mark Hatle
- nativesdk -- runs on the 'sdkhost' (variant called 'crosssdk')
Is this related to the SDKMACHINE setting?
Yes that's the variable I was thinking of. You can build an SDK for 'i586' on your x86_64 host for instance.
--Mark
Quoted 8 lines · Mark Hatle
Quoted 4 lines
Quoted 1 line
- nativesdk -- runs on the 'sdkhost' (variant called 'crosssdk')
Is this related to the SDKMACHINE setting?
Yes that's the variable I was thinking of. You can build an SDK for 'i586' on your
x86_64host for instance.
So in my case, since I did not specify SDKMACHINE, it is creating a toolchain that compiles source into x86_64 executables so it can build the host tools (i.e automake) on the targeted SDK machine. And it has nothing to do with the targeted device cross-compile toolchain?
Quoted 6 lines · Kyle Farnsworth
Quoted 5 lines · Mark Hatle
Quoted 4 lines
Quoted 1 line
- nativesdk -- runs on the 'sdkhost' (variant called 'crosssdk')
Is this related to the SDKMACHINE setting?
Quoted 8 lines
Quoted 3 lines
Yes that's the variable I was thinking of. You can build an SDK for 'i586' on your
x86_64host for instance.So in my case, since I did not specify SDKMACHINE, it is creating a toolchain that compiles source into
x86_64executables so it can build the host tools (i.e automake) on the targeted SDK machine. And it has nothing to do with the targeted device cross-compile toolchain?
You will get a 'cross' compiler from host -> SDK, and another SDK -> target. The SDK -> target is the one that gets installed as part of the SDK.
--Mark
Quoted 6 lines
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core