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