Recently I ran into an issue surrounding a task that we needed to have run after the do_package task because some of its side effects muddied the ${D} directory with files we didn't want to be in our ipk package. We created a task do_create_foo that did the work we needed and set it to run after do_package. To our surprise, the stamp for the task was never created and the task tried to run every a recipe that depended on this one ran. This was especially bad since we use the rm_work class to save disk space, so when do_create_foo was run again, the ${D} was often missing entirely.
Some very long digging later, we discovered that the rm_work class was actually removing the stamp because it wasn't in its hard coded list or in the SSTATETASKS list. Since we didn't want to mess with making the task into an sstate task, we pulled a copy of rm_work.bbclass into our layer and added *do_create_foo* to the case statement in do_rm_work. Your mileage may vary, but hopefully this helps anyone out there with the case of the missing stamp!
Friday, March 16, 2012
Monday, January 30, 2012
Populating sysroot from non-standard paths
Your recipe is finally installing all of the correct files into their correct places during do_install, they are being packaged up properly, but something is still wrong. None of these files are ending up in the sysroot so other packages can make use of them. What's going on?!?
OE-Core only knows about a handful of paths that it should transfer over to the sysroot. In order to teach it about others, you need to define a function that does the populating and then add it to SYSROOT_PREPROCESS_FUNCS. Here's an example for recipe foo:
foo_populate_sysroot() {
sysroot_stage_dir ${D}/my/custom/path ${SYSROOT_DESTDIR}/my/custom/path
}
SYSROOT_PREPROCESS_FUNCS += "foo_populate_sysroot"
This will cause /my/custom/path to be exported to the sysroot and be available for other recipes to use. That's it, you're done! Note that the name of the function can be anything, the above name was used just for clarity.
OE-Core only knows about a handful of paths that it should transfer over to the sysroot. In order to teach it about others, you need to define a function that does the populating and then add it to SYSROOT_PREPROCESS_FUNCS. Here's an example for recipe foo:
foo_populate_sysroot() {
sysroot_stage_dir ${D}/my/custom/path ${SYSROOT_DESTDIR}/my/custom/path
}
SYSROOT_PREPROCESS_FUNCS += "foo_populate_sysroot"
This will cause /my/custom/path to be exported to the sysroot and be available for other recipes to use. That's it, you're done! Note that the name of the function can be anything, the above name was used just for clarity.
Tuesday, October 4, 2011
The importance of base_prefix
Recently I started into converting our -native recipes from oe-classic into oe-core. First try I got a strange error from tar about the path not existing. The path it wanted looked crazy, something like /home/user/Angstrom/build/tmp-angstrom_2010_x-uclibc/work/armv7a-vfp-angstrom-linux-uclibceabi/mypackage-1.0-r0/image///home/user/Angstrom/build/tmp-angstrom_2010_x-uclibc/sysroots/mymachine. Debugging the scripts lead me into a maddening maze. The problem seemed to be emanating from the sstate creation tasks.
It turns out that we were not respecting the ${base_prefix} variable when doing our install. The recipe we were using installs into a non-standard location, so we were installing into something like ${D}/opt/custom-place/ but native recipes actually set the base_prefix to a really strange value like /home/user/Angstrom/build/tmp-angstrom_2010_x-uclibc/sysroots/mymachine. For reference, in normal embedded builds, ${base_prefix} is an empty string.
The fix was simple. Install instead to ${D}${base_prefix}/opt/custom-place/ which installs to the same place it always had during embedded builds, and the long path that tar was looking for during -native builds of the recipe.
Happy building!
It turns out that we were not respecting the ${base_prefix} variable when doing our install. The recipe we were using installs into a non-standard location, so we were installing into something like ${D}/opt/custom-place/ but native recipes actually set the base_prefix to a really strange value like /home/user/Angstrom/build/tmp-angstrom_2010_x-uclibc/sysroots/mymachine. For reference, in normal embedded builds, ${base_prefix} is an empty string.
The fix was simple. Install instead to ${D}${base_prefix}/opt/custom-place/ which installs to the same place it always had during embedded builds, and the long path that tar was looking for during -native builds of the recipe.
Happy building!
Friday, September 30, 2011
What is this blog about exactly?
I'm glad you asked! This blog will be all about my challenges and solutions in creating Embedded Linux platforms, and my musings on computer technology. When I first joined up as a firmware engineer, I was terrified. How could I ever work effectively on such complicated systems? It has been a wild ride and everyday brings new and exciting problems. I can't wait to share them all with you.
Subscribe to:
Posts (Atom)