SDK confusion!

SDK confusion!

[Bjørn Forsman]

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.

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

Re: SDK confusion!

[Mark Hatle]

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

Re: SDK confusion!

[Bjørn Forsman]

Hi Mark,

On 17 December 2012 16:40, Mark Hatle <mark.hatle@windriver.com> 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.
[...]
> 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.

Thank you very much!

"bitbake <image-name> -c populate_sdk" is exactly what I want. Brilliant!

Best regards,
Bjørn Forsman

Re: SDK confusion!

[Bjørn Forsman]

On 17 December 2012 20:58, Bjørn Forsman <bjorn.forsman@gmail.com> wrote:
> Hi Mark,
>
> On 17 December 2012 16:40, Mark Hatle <mark.hatle@windriver.com> 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.
> [...]
>> 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.
>
> Thank you very much!
>
> "bitbake <image-name> -c populate_sdk" is exactly what I want. Brilliant!

Hm, that didn't work so well for me:

bfo@mini:~/setup-scripts [git::master]$ bitbake console-image -c populate_sdk
Loading cache: 100%
|########################################################################################################################################################################|
ETA:  00:00:00
Loaded 2858 entries from dependency cache.

OE Build Configuration:
BB_VERSION        = "1.15.2"
TARGET_ARCH       = "arm"
TARGET_OS         = "linux-gnueabi"
MACHINE           = "beaglebone"
DISTRO            = "angstrom"
DISTRO_VERSION    = "v2012.05"
TUNE_FEATURES     = "armv7a vfp neon cortexa8"
TARGET_FPU        = "vfp-neon"
meta-angstrom     =
"angstrom-v2012.05-yocto1.2:4e15bc5f06ae3c5ad3df1b32a304a4a4c384e788"
meta-oe
toolchain-layer
meta-efl
meta-gpe
meta-gnome
meta-xfce
meta-initramfs    = "denzil:e77646bc2cf905fd671fc5c19ab6fd17f9b94b3f"
meta-opie         = "master:efa3892b20a4ef80274e56e5633ebd62c16f9731"
meta-java         = "master:3386ea6c96096f107f43f282f654e5afa456109e"
meta-browser      = "master:c47f59df2e723495679c751cbdf6a8c6adec4b6a"
meta-mono         = "master:83f8233b0498aadb18bf7605c3ba6c71d9e13a3a"
meta-kde          = "master:5b0882d951cfd71886d423c190faaa7c7f932333"
meta-ti           =
"angstrom-staging-yocto1.2:edfd9649cbd16b2cdb5385954c0441c7bba92f8d"
meta-efikamx      = "master:2c09a3a780b23448e8a6ca964256ff7f5ccba65d"
meta-nslu2        = "master:3d9fc951b05b4df476374b6fc3085ebac7f293ee"
meta-htc
meta-nokia
meta-openmoko
meta-palm         = "master:2b106be01228f64298d6cb338f93088806594344"
meta-handheld     = "master:1f05a15aceb4c3a19fa070463b58125b5658b2a9"
meta-raspberrypi  = "denzil:34eef2ea4f5f24630dbb73b386861430167b8431"
meta-intel
meta-sugarbay
meta-crownbay
meta-emenlow
meta-fishriver
meta-fri2
meta-jasperforest
meta-n450         = "master:f75f9b6f68473eb0efac802409608f8389be0030"
meta              = "denzil:d35560f33f257bd12a07c7c0be770319086d6ad9"

NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
ERROR: Task do_populate_sdk does not exist for target console-image

Summary: There was 1 ERROR message shown, returning a non-zero exit code.
bfo@mini:~/setup-scripts [git::master]$


Suggestions?

Best regards,
Bjørn Forsman

Re: SDK confusion!

[Mark Hatle]

On 12/17/12 4:11 PM, Bjørn Forsman wrote:
> On 17 December 2012 20:58, Bjørn Forsman <bjorn.forsman@gmail.com> wrote:
>> Hi Mark,
>>
>> On 17 December 2012 16:40, Mark Hatle <mark.hatle@windriver.com> 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.
>> [...]
>>> 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.
>>
>> Thank you very much!
>>
>> "bitbake <image-name> -c populate_sdk" is exactly what I want. Brilliant!
>
> Hm, that didn't work so well for me:
>
> bfo@mini:~/setup-scripts [git::master]$ bitbake console-image -c populate_sdk
> Loading cache: 100%
> |########################################################################################################################################################################|
> ETA:  00:00:00
> Loaded 2858 entries from dependency cache.
>
> OE Build Configuration:
> BB_VERSION        = "1.15.2"
> TARGET_ARCH       = "arm"
> TARGET_OS         = "linux-gnueabi"
> MACHINE           = "beaglebone"
> DISTRO            = "angstrom"
> DISTRO_VERSION    = "v2012.05"
> TUNE_FEATURES     = "armv7a vfp neon cortexa8"
> TARGET_FPU        = "vfp-neon"
> meta-angstrom     =
> "angstrom-v2012.05-yocto1.2:4e15bc5f06ae3c5ad3df1b32a304a4a4c384e788"
> meta-oe
> toolchain-layer
> meta-efl
> meta-gpe
> meta-gnome
> meta-xfce
> meta-initramfs    = "denzil:e77646bc2cf905fd671fc5c19ab6fd17f9b94b3f"
> meta-opie         = "master:efa3892b20a4ef80274e56e5633ebd62c16f9731"
> meta-java         = "master:3386ea6c96096f107f43f282f654e5afa456109e"
> meta-browser      = "master:c47f59df2e723495679c751cbdf6a8c6adec4b6a"
> meta-mono         = "master:83f8233b0498aadb18bf7605c3ba6c71d9e13a3a"
> meta-kde          = "master:5b0882d951cfd71886d423c190faaa7c7f932333"
> meta-ti           =
> "angstrom-staging-yocto1.2:edfd9649cbd16b2cdb5385954c0441c7bba92f8d"
> meta-efikamx      = "master:2c09a3a780b23448e8a6ca964256ff7f5ccba65d"
> meta-nslu2        = "master:3d9fc951b05b4df476374b6fc3085ebac7f293ee"
> meta-htc
> meta-nokia
> meta-openmoko
> meta-palm         = "master:2b106be01228f64298d6cb338f93088806594344"
> meta-handheld     = "master:1f05a15aceb4c3a19fa070463b58125b5658b2a9"
> meta-raspberrypi  = "denzil:34eef2ea4f5f24630dbb73b386861430167b8431"
> meta-intel
> meta-sugarbay
> meta-crownbay
> meta-emenlow
> meta-fishriver
> meta-fri2
> meta-jasperforest
> meta-n450         = "master:f75f9b6f68473eb0efac802409608f8389be0030"
> meta              = "denzil:d35560f33f257bd12a07c7c0be770319086d6ad9"
>
> NOTE: Resolving any missing task queue dependencies
> NOTE: Preparing runqueue
> ERROR: Task do_populate_sdk does not exist for target console-image
>
> Summary: There was 1 ERROR message shown, returning a non-zero exit code.
> bfo@mini:~/setup-scripts [git::master]$

See above:

 > meta-angstrom     =
 > "angstrom-v2012.05-yocto1.2:4e15bc5f06ae3c5ad3df1b32a304a4a4c384e788"

This is Yocto Project 1.2, the feature arrived sometime between 1.2 and 1.3.

The 'danny' branch is 1.3, 'denzil' is 1.2.  I may have said 'denzil' by 
accident in the last email.

Basically you need a newer oe-core to use this feature, or you need to backport it.

--Mark

>
> Suggestions?
>
> Best regards,
> Bjørn Forsman
>

Re: SDK confusion!

[Bjørn Forsman]

On 17 December 2012 23:20, Mark Hatle <mark.hatle@windriver.com> wrote:
[...]
> This is Yocto Project 1.2, the feature arrived sometime between 1.2 and 1.3.
>
> The 'danny' branch is 1.3, 'denzil' is 1.2.  I may have said 'denzil' by
> accident in the last email.
>
> Basically you need a newer oe-core to use this feature, or you need to
> backport it.

Ok. I have switched branches now and got it working for
core-image-minimal. Thanks.

However, the systemd-image in Angstrom has an issue that breaks
"bitbake systemd-image -c populate_sdk". I have posted a message on
their list just now. But basically, the error is this:

$ bitbake systemd-image -c populate_sdk
[...]
| Package netbase-dbg (5.0-r1) installed in root is up to date.
| Collected errors:
|  * check_conflicts_for: The following packages conflict with openssh:
|  * check_conflicts_for: 	dropbear *
|  * opkg_install_cmd: Cannot install package openssh-dev.
|  * check_conflicts_for: The following packages conflict with openssh:
|  * check_conflicts_for: 	dropbear *
|  * opkg_install_cmd: Cannot install package openssh-dbg.
| DEBUG: Python function do_populate_sdk finished
| ERROR: Function failed: populate_sdk_image (see
/home/bfo/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/work/beaglebone-angstrom-linux-gnueabi/systemd-image-1.0-r0/temp/log.do_populate_sdk.18052
for further information)
ERROR: Task 10 (/home/bfo/setup-scripts/sources/meta-angstrom/recipes-images/angstrom/systemd-image.bb,
do_populate_sdk) failed with exit code '1'

Best regards,
Bjørn Forsman

Re: SDK confusion!

[Mark Hatle]

On 12/18/12 7:50 AM, Bjørn Forsman wrote:
> On 17 December 2012 23:20, Mark Hatle <mark.hatle@windriver.com> wrote:
> [...]
>> This is Yocto Project 1.2, the feature arrived sometime between 1.2 and 1.3.
>>
>> The 'danny' branch is 1.3, 'denzil' is 1.2.  I may have said 'denzil' by
>> accident in the last email.
>>
>> Basically you need a newer oe-core to use this feature, or you need to
>> backport it.
>
> Ok. I have switched branches now and got it working for
> core-image-minimal. Thanks.
>
> However, the systemd-image in Angstrom has an issue that breaks
> "bitbake systemd-image -c populate_sdk". I have posted a message on
> their list just now. But basically, the error is this:
>
> $ bitbake systemd-image -c populate_sdk
> [...]
> | Package netbase-dbg (5.0-r1) installed in root is up to date.
> | Collected errors:
> |  * check_conflicts_for: The following packages conflict with openssh:
> |  * check_conflicts_for: 	dropbear *
> |  * opkg_install_cmd: Cannot install package openssh-dev.
> |  * check_conflicts_for: The following packages conflict with openssh:
> |  * check_conflicts_for: 	dropbear *
> |  * opkg_install_cmd: Cannot install package openssh-dbg.

Both dropbear and openssh appear to not be able to be installed at the same time 
due to a stated package conflict.  As to why they are bothy trying to be 
installed, I'm not sure.  Sorry.

--Mark

> | DEBUG: Python function do_populate_sdk finished
> | ERROR: Function failed: populate_sdk_image (see
> /home/bfo/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/work/beaglebone-angstrom-linux-gnueabi/systemd-image-1.0-r0/temp/log.do_populate_sdk.18052
> for further information)
> ERROR: Task 10 (/home/bfo/setup-scripts/sources/meta-angstrom/recipes-images/angstrom/systemd-image.bb,
> do_populate_sdk) failed with exit code '1'
>
> Best regards,
> Bjørn Forsman
>

Re: SDK confusion!

[Mark Hatle]

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
>