Re: SDK confusion!

[Mark Hatle <mark.hatle@windriver.com>]

On 12/17/12 9:40 AM, Mark Hatle wrote:
> 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.

Just correcting this for anyone who may be looking at these emails in the 
future.  It's the 'danny' branch -not- the denzil where this change exists.

--Mark

> 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@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>