Adding ALSA to the Yocto SDK

Adding ALSA to the Yocto SDK

[Patrick Turley]

I've been working on re-targeting some code from a vendor's board to our own board.

For libraries and other low-level code, everything's been fine. For test applications, I'm running into a dependency on the header file alsa/asoundlib.h, which is obviously part of ALSA.

I've been building our SDK with:

    bitbake meta-toolchain-sdk

This gives us most everything we need, but it does *not* include header files and libraries for ALSA. That actually seems perfectly reasonable to me -- not everyone needs ALSA support in their applications, so the *default* SDK shouldn't be burdened with that.

We *do* need it. As I see it, there are two possibilities:

1) There's something I can do that will cause OE/Yocto to include ALSA header files in the SDK I produce. If that's the case, can you tell me what I need to do?

2) The ALSA header files aren't *supposed* to be in the SDK -- I'm supposed to be delivering them to the compilation process in another way. If that's the case, can you tell me what I need to do?


Other items of note…

-- Executing "bitbake alsa-lib" *did* put the expected files within our sysroot (under tmp/sysroots). Even so (as we intuitively expected) executing "bitbake meta-toolchain-sdk" afterward did *not* put them into the SDK. We conclude that having a package built and available for the SDK doesn't necessarily get it into the SDK.

-- Adding ALSA to our image also caused the correct files to end up in our sysroot but, again, nothing appeared in the SDK. We conclude that the contents of the image do *not* dictate the contents of the SDK.

Re: Adding ALSA to the Yocto SDK

[Zhang, Jessica]

Hi Patrick,

Since you're able to add the dev packages to images, just do bitbake yourimagewithALSA -c populate_sdk, that should generate a SDK contains ALSA.  By default, meta-toolchain-sdk is predefined unless you use "-c populate_sdk" to enforce the SDK sysroot to match your rootfs.

Cheers,
Jessica

-----Original Message-----
From: yocto-bounces@yoctoproject.org [mailto:yocto-bounces@yoctoproject.org] On Behalf Of Patrick Turley
Sent: Monday, January 21, 2013 1:27 PM
To: yocto@yoctoproject.org
Subject: [yocto] Adding ALSA to the Yocto SDK

I've been working on re-targeting some code from a vendor's board to our own board.

For libraries and other low-level code, everything's been fine. For test applications, I'm running into a dependency on the header file alsa/asoundlib.h, which is obviously part of ALSA.

I've been building our SDK with:

    bitbake meta-toolchain-sdk

This gives us most everything we need, but it does *not* include header files and libraries for ALSA. That actually seems perfectly reasonable to me -- not everyone needs ALSA support in their applications, so the *default* SDK shouldn't be burdened with that.

We *do* need it. As I see it, there are two possibilities:

1) There's something I can do that will cause OE/Yocto to include ALSA header files in the SDK I produce. If that's the case, can you tell me what I need to do?

2) The ALSA header files aren't *supposed* to be in the SDK -- I'm supposed to be delivering them to the compilation process in another way. If that's the case, can you tell me what I need to do?


Other items of note...

-- Executing "bitbake alsa-lib" *did* put the expected files within our sysroot (under tmp/sysroots). Even so (as we intuitively expected) executing "bitbake meta-toolchain-sdk" afterward did *not* put them into the SDK. We conclude that having a package built and available for the SDK doesn't necessarily get it into the SDK.

-- Adding ALSA to our image also caused the correct files to end up in our sysroot but, again, nothing appeared in the SDK. We conclude that the contents of the image do *not* dictate the contents of the SDK.

_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: Adding ALSA to the Yocto SDK

[Jack Mitchell]

On 01/21/13 21:27, Patrick Turley wrote:
> I've been working on re-targeting some code from a vendor's board to our own board.
>
> For libraries and other low-level code, everything's been fine. For test applications, I'm running into a dependency on the header file alsa/asoundlib.h, which is obviously part of ALSA.
>
> I've been building our SDK with:
>
>      bitbake meta-toolchain-sdk
>
> This gives us most everything we need, but it does *not* include header files and libraries for ALSA. That actually seems perfectly reasonable to me -- not everyone needs ALSA support in their applications, so the *default* SDK shouldn't be burdened with that.
>
> We *do* need it. As I see it, there are two possibilities:
>
> 1) There's something I can do that will cause OE/Yocto to include ALSA header files in the SDK I produce. If that's the case, can you tell me what I need to do?
>
> 2) The ALSA header files aren't *supposed* to be in the SDK -- I'm supposed to be delivering them to the compilation process in another way. If that's the case, can you tell me what I need to do?
>
>
> Other items of note…
>
> -- Executing "bitbake alsa-lib" *did* put the expected files within our sysroot (under tmp/sysroots). Even so (as we intuitively expected) executing "bitbake meta-toolchain-sdk" afterward did *not* put them into the SDK. We conclude that having a package built and available for the SDK doesn't necessarily get it into the SDK.
>
> -- Adding ALSA to our image also caused the correct files to end up in our sysroot but, again, nothing appeared in the SDK. We conclude that the contents of the image do *not* dictate the contents of the SDK.
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Hi Patrick,

I'm sure someone very knowledgeable wull be about soon. But if you're 
running a fairly recent build then you will be able to execute:

bitbake your-image -c populate_sdk

which will build a custom sdk which will match the libs and files on in 
'your-image' exactly.

meta-toolchain-sdk is an odd beast, as it is not related to anything 
apart from being a generic toolchain with some base libs included. I 
also fell into this trap, in order to get a custom sdk which you can 
build like this, you must copy the meta-toolchain-sdk image and 
add/remove packages as you would in a target image.

Hope this helps!
Regards,
Jack.

Re: Adding ALSA to the Yocto SDK

[Patrick Turley]

On Jan 21, 2013, at 4:35 PM, "Zhang, Jessica" <jessica.zhang@intel.com> wrote:

> Hi Patrick,
> 
> Since you're able to add the dev packages to images, just do bitbake yourimagewithALSA -c populate_sdk, that should generate a SDK contains ALSA.  By default, meta-toolchain-sdk is predefined unless you use "-c populate_sdk" to enforce the SDK sysroot to match your rootfs.


All the clues rolling in are starting to knit together.

At first, I regarded the "populate_sdk" task as a hack, since it seemed to be expressing something that was naturally a "target" -- not a "task."

Now I see that it is a way to connect an image to a corresponding SDK. That makes a *lot* more sense.

Re: Adding ALSA to the Yocto SDK

[Patrick Turley]

On Jan 21, 2013, at 5:16 PM, Patrick Turley <PatrickTurley@gamestop.com> wrote:

> On Jan 21, 2013, at 4:35 PM, "Zhang, Jessica" <jessica.zhang@intel.com> wrote:
> 
>> Hi Patrick,
>> 
>> Since you're able to add the dev packages to images, just do bitbake yourimagewithALSA -c populate_sdk, that should generate a SDK contains ALSA.  By default, meta-toolchain-sdk is predefined unless you use "-c populate_sdk" to enforce the SDK sysroot to match your rootfs.
> 
> 
> All the clues rolling in are starting to knit together.
> 
> At first, I regarded the "populate_sdk" task as a hack, since it seemed to be expressing something that was naturally a "target" -- not a "task."
> 
> Now I see that it is a way to connect an image to a corresponding SDK. That makes a *lot* more sense.

One of my colleagues did some research on this and I believe we've found the best way for *us* to do this.

We tried using a single image recipe. We tried both bitbake'ing this recipe directly *and* using the "populate_sdk" task with it. This gave us the SDK we needed, but it resulted in development header files appearing in the target root file system.

Like core-image-sato and core-image-sato-sdk, we'll have have two images:

1) A target image recipe.
We will bitbake this recipe directly to produce the target image. We will *never* use the "populate_sdk" task with this recipe.

2) An SDK image recipe.
This recipe "require's" the target image recipe and adds various development packages to it. We will *never* bitbake this recipe directly because we have no interest in the root file system it would produce. We will *only* use the "populate_sdk" task with this recipe.

This gives us the clean target root file system we need *and* the SDK we need.

The disadvantage is that we have to keep two recipe files in sync with each other. Fortunately, these are low-frequency and low-volume changes, so we think this is a reasonable trade-off.