search

agherzan / meta-raspberrypi

Yocto/OE BSP layer for the Raspberry Pi boards
https://www.yoctoproject.org/
MIT License
532 stars 410 forks source link

Empty bcm28355 package #22

Closed simark closed 7 years ago

simark commented 8 years ago

When I add bcm2835 to my IMAGE_INSTALL variable, the do_rootfs step of my image fails, i think because no bcm2835 package is generated (as it would be empty). In my log.do_rootfs:

...
Unknown package 'bcm2835'.
...
Collected errors:
 * opkg_install: Cannot install package bcm2835.
...

And indeed, no bcm2835 package is generated:

$ ls -1 tmp/deploy/ipk/cortexa7hf-neon-vfpv4/*bcm2835*
tmp/deploy/ipk/cortexa7hf-neon-vfpv4/bcm2835-dbg_1.46-r0_cortexa7hf-neon-vfpv4.ipk
tmp/deploy/ipk/cortexa7hf-neon-vfpv4/bcm2835-dev_1.46-r0_cortexa7hf-neon-vfpv4.ipk
tmp/deploy/ipk/cortexa7hf-neon-vfpv4/bcm2835-staticdev_1.46-r0_cortexa7hf-neon-vfpv4.ipk
tmp/deploy/ipk/cortexa7hf-neon-vfpv4/bcm2835-tests_1.46-r0_cortexa7hf-neon-vfpv4.ipk

By allowing an empty package to be created, the do_rootfs step finishes cleanly.

diff --git a/recipes-devtools/bcm2835/bcm2835_1.46.bb b/recipes-devtools/bcm2835/bcm2835_1.46.bb
index dd37b8f..09fcab8 100644
--- a/recipes-devtools/bcm2835/bcm2835_1.46.bb
+++ b/recipes-devtools/bcm2835/bcm2835_1.46.bb
@@ -35,6 +35,8 @@ do_install_append() {

 PACKAGES += "${PN}-tests"

+ALLOW_EMPTY_${PN} = "1"
+
 FILES_${PN} = ""
 FILES_${PN}-tests = "${libdir}/${BPN}"
 FILES_${PN}-dbg += "${libdir}/${BPN}/.debug"

Am I doing something wrong? Am I supposed to put bcm2835 somewhere else than IMAGE_INSTALL, or am I supposed to used something else than bcm2835?

agherzan commented 8 years ago

Hi @simark . Indeed this is the case. the package creates some tests and a static library. So these would make sense only on dev. Are you going to compile stuff on board? Why do you need this package on board?

simark commented 8 years ago

Indeed, from what I understand, I only want bcm2835-staticdev to end up in the SDK, so that it can be used when writing applications. How would you do this?

I have tried

TOOLCHAIN_HOST_TASK_append = " bcm2835-staticdev"

but it doesn't work when I do the populate_sdk task:

ERROR: polarsys-img-1.0-r0 do_populate_sdk: Unable to install packages. Command '/home/user/polarsys-os/build/tmp/sysroots/x86_64-linux/usr/bin/opkg --volatile-cache -f /home/user/polarsys-os/build/tmp/work/raspberrypi2-poky-linux-gnueabi/polarsys-img/1.0-r0/opkg-sdk.conf -o /home/user/polarsys-os/build/tmp/work/raspberrypi2-poky-linux-gnueabi/polarsys-img/1.0-r0/sdk/image  --force_postinstall --prefer-arch-to-version   install nativesdk-packagegroup-sdk-host packagegroup-cross-canadian-raspberrypi2 bcm2835-staticdev' returned 255:
Collected errors:
 * opkg_prepare_url_for_install: Couldn't find anything to satisfy 'bcm2835-staticdev'.

I also tried

TOOLCHAIN_TARGET_TASK_append = " bcm2835-staticdev"

but also got an error:

Collected errors:
 * Cannot satisfy the following dependencies for bcm2835-staticdev:
 *  bcm2835 (= 1.46-r0) * 
 * opkg_install: Cannot install package bcm2835-staticdev.

How are we supposed the to use this recipe?

agherzan commented 8 years ago

Now I got it. You use it from the SDK. That makes sense in that case. I'm not a SDK user so the only way I would use it is though a build based on sysroot.

simark commented 8 years ago

Could you define

a build based on sysroot.

? The SDK is essentially two sysroots (target and host).

Thanks for your help, I am trying to grasp the magic in Yocto, and it's a bit hard as I find the documentation a bit sparse.

simark commented 8 years ago

Perhaps the right way would be to remove the (automatic/implicit I suppose) dependency of the -staticdev package on the main package? A bit like what was done here:

http://lists.openembedded.org/pipermail/openembedded-core/2012-July/065226.html

agherzan commented 8 years ago

Very good catch. That might work just fine for you. Can you check?

What I mean is that I never used the artifacts from this recipe in a SDK. The way I used it is by having another recipe which depends on it and compiles stuff by getting this static library form sysroot.

simark commented 8 years ago

Very good catch. That might work just fine for you. Can you check?

Yes, adding

RDEPENDS_${PN}-staticdev = ""

makes it so that I can use 

TOOLCHAIN_TARGET_TASK_append = " bcm2835-staticdev"

in my image, and I end up with

/opt/poky/2.1+snapshot/sysroots/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/usr/lib/libbcm2835.a

in my SDK, so I guess it's good! I think it doesn't carry very well the intent though. I suppose that something like

RDEPENDS_${PN}-staticdev_remove = "${PN}"

but I haven't tested it.

What I mean is that I never used the artifacts from this recipe in a SDK. The way I used it is by having another recipe which depends on it and compiles stuff by getting this static library form sysroot.

Ah ok so you compile your other software as part of the Yocto build.

agherzan commented 8 years ago

Please push a patch for the RDEPENDS fix. That seems like the right way forward. RDEPENDS_${PN}-staticdev = ""

simark commented 8 years ago

I have looked at it a bit more, and I think it should be 

RDEPENDS_${PN}-dev = ""

The -staticdev package only includes the static library (libbcm2835.a), whereas the -dev package only includes the header (bcm2835.h). In order to do anything useful, we need both. In the default rules in ${pokyrepo}/meta/conf/bitbake.conf, we can see that -staticdev depends on -dev:

RDEPENDS_${PN}-staticdev = "${PN}-dev (= ${EXTENDPKGV})"

while -dev depends on the main package:

RDEPENDS_${PN}-dev = "${PN} (= ${EXTENDPKGV})"

Therefore, clearing RDEPENDS_${PN}-dev would make more sense, as using the -staticdev would also pull the -dev. Since both packages are required together to do anything useful, I would even consider also making the -dev depend in the -staticdev. However, I don't know if circular dependencies are nicely handled by bitbake or not...

I am testing this, I'll post a patch once I'm done.

79rpm commented 3 years ago

Hello, thank you for reporting and solving this issue. Are there any places where the need to write bcm2835-dev is documented besides this issue report page? I came across the issue today while adding the recipe to my build with Yocto saying "No match for argument: bcm2835" followed by "Error: Unable to find a match".

agherzan commented 3 years ago

I'm not sure I understand what you tried, your setup, and what the error is. Could you please detail?

carlesole commented 2 years ago

Hello @agherzan ,

I just have a doubt how to get the libbcm2835.a into the image as you mentioned. I managed to get it in my sdk as mentioned by @simark in /opt/agl-sdk/12.0.1-aarch64/sysroots/aarch64-agl-linux/usr/lib (I am using an agl build).

However I would also like to be able to have it build in in my normal image in case I want to compile something directly in the rpi instead of in my host machine. However in my image I only have the header bcm2835.h but not the library, hence I cannot link it.

In order to get the library built in the sdk I added the following in ./agl_lamprey/meta-agl/meta-agl-bsp/conf/agl_raspberrypi4.inc

IMAGE_INSTALL_append = "bcm2835-dev "

However in my "normal" image the library is not available. What do I need to do to get the library built in my image?

agherzan commented 2 years ago

Here are some items to check:

carlesole commented 2 years ago

Hello @agherzan,

thanks for your quick reply.

agherzan commented 2 years ago

Can you replicate this on master and provide me with a simple use case using meta-raspberrypi alone (with oe-core)?

carlesole commented 2 years ago

Hi @agherzan,

I just did as you asked. if I add following in local.conf: IMAGE_INSTALL:append = " bcm2835-staticdev"

then both the header bcm2835.h and the static library libbcm2835.a get generated in

oe-core/build/tmp-glibc/work/raspberrypi4_64-oe-linux/core-image-minimal/1.0-r0/rootfs/usr/include oe-core/build/tmp-glibc/work/raspberrypi4_64-oe-linux/core-image-minimal/1.0-r0/rootfs/usr/lib

respectively. If instead I write IMAGE_INSTALL:append = " bcm2835-dev" only the header file is generated. Maybe this is the expected behavior. This also works on my agl image, only difference is that I need to use IMAGE_INSTALL_append because my version is based on "dunfell".

What I find slightly confusing is that in case of the crosssdk image only by adding IMAGE_INSTALL_append = " bcm2835-dev" in local.conf it does generate the header and the library in sysroots of the sdk. Any idea why the behavior is different?

The use case would be for example to just compile a main.c which includes bcm2835.h directly in the rpi4, like

gcc main.c -o test -lbcm2835

Thanks for the support, Carles

kraj commented 2 years ago

I just did as you asked. if I add following in local.conf: IMAGE_INSTALL:append = " bcm2835-staticdev"

then both the header bcm2835.h and the static library libbcm2835.a get generated in

staticdev depends on dev so when you add staticdev to image it pulls in dev automatically and dev will provide the needed header while staticdev will provide library archive and complete your solution. Generally yocto defaults are to not include static archives in development images due to linking concerns and accidental inclusion of incompatible licenses into binaries.

Yocto project reference distro ( poky ) does this by default see

https://github.com/yoctoproject/poky/blob/master/meta-poky/conf/distro/poky.conf#L59