[OE-core] SDK confusion!

Mark Hatle mark.hatle at windriver.com
Mon Dec 17 15:40:51 UTC 2012


On 12/17/12 9:31 AM, Bjørn Forsman wrote:
> Hi,
>
> I'm really confused about how to use/customize the generated SDK in
> openembedded. I've spent two days messing around with angstrom
> setup-scripts, poky and yocto and now I really need help.
>
> First I did "bitbake meta-toolchain" (and installed it). That gave me
> a toolchain, but no extra libraries. Then I tried "bitbake
> meta-toolchain-sdk" and I got some extra libraries (yay!). But looking
> at the respective recipies for these meta-tasks and I have *no idea*
> what libraries "meta-toolchain-sdk" includes. I'm not comfortable with
> the latter target *accidentally* happen to include the libraries I
> need.

In oe-core with the branch tag 'denzil' or the master, there are two ways of 
generating an SDK.

The first (which is also present in the older oe-core systems) uses a specific 
SDK recipe.  For instance, meta-toolchain.  This recipe simply makes the 
toolchain elements available to you and you need to provide the necessary 
sysroot for your SDK.  An alternative is something like meta-toolchain-gmae 
which provides a specific set of sysroot components for the 'gnome mobile 
applicable environment.'

The advantage of this first way is it allows a product designer to release a 
targeted SDK for their application developers.  You don't have to put everything 
that will end up on the target image into the SDK, only the libraries, headers 
and interfaces that an app developer are allowed to use.

The second way (which is newer) is the ability to generate an SDK based on the 
contents of the image.  This uses a new task called "populate_sdk" that can be 
run with any image recipe, i.e. "bitbake core-image-minimal -c populate_sdk". 
This will generate an SDK image that includes the software from the image, in 
addition to related -dev and -dbg packages.

The advantage of this second way is that you have an SDK that enables developing 
for the contents of the image, as well as system wide cross-debugging with the 
-dbg packages.


The items below are specific to one packaging system, opkg.  The items above are 
generic and are expected to work in any of the supported methods.

> After searching the web for a bit, I discovered the "opkg-target"
> command. Turns out that this command (or alias) no longer exist. Now
> I'm supposed to use "opkg-cl". The yocto documentation says I should
> do this:
>
> $ opkg-cl –f <conf_file> -o <sysroot_dir> update
> $ opkg-cl –f <cconf_file> -o <sysroot_dir> --force-overwrite install libglade
> $ opkg-cl –f <cconf_file> -o <sysroot_dir> --force-overwrite install
> libglade-dbg
> $ opkg-cl –f <conf_file> -o <sysroot_dir> --force-overwrite install libglade-dev
>
> Let's see, there are two sysroots installed by the toolchain:
> /usr/local/oecore-x86_64/sysroots/x86_64-angstromsdk-linux
> /usr/local/oecore-x86_64/sysroots/armv7a-angstrom-linux-gnueabi/
>
> After messing around with the various combinations of <conf_file> and
> <sysroot_dir>, the closest I get to somthing working is this:
>
> $ . /usr/local/oecore-x86_64/environment-setup-armv7a-angstrom-linux-gnueabi
> $ opkg-cl -f /usr/local/oecore-x86_64/sysroots/armv7a-angstrom-linux-gnueabi/etc/opkg-sdk.conf
> -o /usr/local/oecore-x86_64/sysroots/armv7a-angstrom-linux-gnueabi/
> update
> [snip lots of "Package XXX has no valid architecture, ignoring"]
> Package libsystemd-id128-0 version v44-45-g3eff420-r28 has no valid
> architecture, ignoring.
> Package pam-plugin-shells version 1.1.5-r5 has no valid architecture, ignoring.
> Package coreutils-dbg version 8.14-r3 has no valid architecture, ignoring.
> Package ocf-linux version 20100325-r3.0 has no valid architecture, ignoring.
> Package libxdamage-dev version 1:1.1.3-r1 has no valid architecture, ignoring.
> Downloading file:/home/bfo/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/deploy/ipk/Packages.
> Updated list of available packages in
> /usr/local/oecore-x86_64/sysroots/armv7a-angstrom-linux-gnueabi///var/lib/opkg/lists/oe.
> Downloading file:/home/bfo/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/deploy/ipk/all/Packages.
> Updated list of available packages in
> /usr/local/oecore-x86_64/sysroots/armv7a-angstrom-linux-gnueabi///var/lib/opkg/lists/oe-all.
> Downloading file:/home/bfo/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/deploy/ipk/x86_64-nativesdk/Packages.
> Updated list of available packages in
> /usr/local/oecore-x86_64/sysroots/armv7a-angstrom-linux-gnueabi///var/lib/opkg/lists/oe-x86_64-nativesdk.
>
> I've also run "bitbake package-index", but it didn't change anything.
>
> Can someone please explain how to control what goes into the SDK?
>
> If possible, I'd like to configure the SDK contents in a file rather
> than running a bunch of opkg-cl commands afterwards. I like
> reproducible builds, and if I have to run opkg-cl commands afterwards
> I will have to document/script that too. Configuration managment is
> difficult enough as it is :-)
>
> Best regards,
> Bjørn Forsman
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>





More information about the Openembedded-core mailing list