14.1. |
How does Poky differ from OpenEmbedded? |
The term "Poky" refers to the specific reference build system that the Yocto Project provides. Poky is based on OE-Core and BitBake. Thus, the generic term used here for the build system is the "OpenEmbedded build system." Development in the Yocto Project using Poky is closely tied to OpenEmbedded, with changes always being merged to OE-Core or BitBake first before being pulled back into Poky. This practice benefits both projects immediately. |
|
14.2. |
My development system does not meet the required Git, tar, and Python versions. In particular, I do not have Python 3.4.0 or greater. Can I still use the Yocto Project? |
You can get the required tools on your host development system a couple different ways (i.e. building a tarball or downloading a tarball). See the "Required Git, tar, and Python Versions" section for steps on how to update your build tools. |
|
14.3. |
How can you claim Poky / OpenEmbedded-Core is stable? |
There are three areas that help with stability;
|
|
14.4. |
How do I get support for my board added to the Yocto Project? |
Support for an additional board is added by creating a Board Support Package (BSP) layer for it. For more information on how to create a BSP layer, see the "Understanding and Creating Layers" section in the Yocto Project Development Manual and the Yocto Project Board Support Package (BSP) Developer's Guide. Usually, if the board is not completely exotic, adding support in the Yocto Project is fairly straightforward. |
|
14.5. |
Are there any products built using the OpenEmbedded build system? |
The software running on the Vernier LabQuest is built using the OpenEmbedded build system. See the Vernier LabQuest website for more information. There are a number of pre-production devices using the OpenEmbedded build system and the Yocto Project team announces them as soon as they are released. |
|
14.6. |
What does the OpenEmbedded build system produce as output? |
Because you can use the same set of recipes to create output of various formats, the output of an OpenEmbedded build depends on how you start it. Usually, the output is a flashable image ready for the target device. |
|
14.7. |
How do I add my package to the Yocto Project? |
To add a package, you need to create a BitBake recipe. For information on how to create a BitBake recipe, see the "Writing a New Recipe" in the Yocto Project Development Manual. |
|
14.8. |
Do I have to reflash my entire board with a new Yocto Project image when recompiling a package? |
The OpenEmbedded build system can build packages in various
formats such as IPK for OPKG, Debian package
( |
|
14.9. |
I see the error ' |
You are probably running the build on an NTFS filesystem.
Use |
|
14.10. |
I see lots of 404 responses for files on
|
Nothing is wrong. The OpenEmbedded build system checks any configured source mirrors before downloading from the upstream sources. The build system does this searching for both source archives and pre-checked out versions of SCM-managed software. These checks help in large installations because it can reduce load on the SCM servers themselves. The address above is one of the default mirrors configured into the build system. Consequently, if an upstream source disappears, the team can place sources there so builds continue to work. |
|
14.11. |
I have machine-specific data in a package for one machine only but the package is being marked as machine-specific in all cases, how do I prevent this? |
Set |
|
14.12. |
I'm behind a firewall and need to use a proxy server. How do I do that? |
Most source fetching by the OpenEmbedded build system is done
by
Following is the applicable code for setting various proxy
types in the # You can set the default proxies for Wget to use for http, https, and ftp. # They will override the value in the environment. #https_proxy = http://proxy.yoyodyne.com:18023/ #http_proxy = http://proxy.yoyodyne.com:18023/ #ftp_proxy = http://proxy.yoyodyne.com:18023/ # If you do not want to use proxy at all, set this to off. #use_proxy = on
The Yocto Project also includes a
|
|
14.13. |
What’s the difference between |
The |
|
14.14. |
I'm seeing random build failures. Help?! |
If the same build is failing in totally different and random ways, the most likely explanation is:
The OpenEmbedded build system processes a massive amount of data that causes lots of network, disk and CPU activity and is sensitive to even single-bit failures in any of these areas. True random failures have always been traced back to hardware or virtualization issues. |
|
14.15. |
When I try to build a native recipe, the build fails with |
If you get an error message that indicates GNU
#error GNU libiconv not in use but included iconv.h is from libiconv If you find a previously installed file, you should either uninstall it or temporarily rename it and try the build again.
This issue is just a single manifestation of "system
leakage" issues caused when the OpenEmbedded build system
finds and uses previously installed files during a native
build.
This type of issue might not be limited to
|
|
14.16. |
What do we need to ship for license compliance? |
This is a difficult question and you need to consult your lawyer for the answer for your specific case. It is worth bearing in mind that for GPL compliance, there needs to be enough information shipped to allow someone else to rebuild and produce the same end result you are shipping. This means sharing the source code, any patches applied to it, and also any configuration information about how that package was configured and built. You can find more information on licensing in the "Licensing" and "Maintaining Open Source License Compliance During Your Product's Lifecycle" sections, both of which are in the Yocto Project Development Manual. |
|
14.17. |
How do I disable the cursor on my touchscreen device? |
You need to create a form factor file as described in the
"Miscellaneous BSP-Specific Recipe Files"
section in the Yocto Project Board Support Packages (BSP)
Developer's Guide.
Set the HAVE_TOUCHSCREEN=1
|
|
14.18. |
How do I make sure connected network interfaces are brought up by default? |
The default interfaces file provided by the netbase recipe does not automatically bring up network interfaces. Therefore, you will need to add a BSP-specific netbase that includes an interfaces file. See the "Miscellaneous BSP-Specific Recipe Files" section in the Yocto Project Board Support Packages (BSP) Developer's Guide for information on creating these types of miscellaneous recipe files. For example, add the following files to your layer: meta-MACHINE/recipes-bsp/netbase/netbase/MACHINE/interfaces meta-MACHINE/recipes-bsp/netbase/netbase_5.0.bbappend
|
|
14.19. |
How do I create images with more free space? |
By default, the OpenEmbedded build system creates images that are 1.3 times the size of the populated root filesystem. To affect the image size, you need to set various configurations:
|
|
14.20. |
Why don't you support directories with spaces in the pathnames? |
The Yocto Project team has tried to do this before but too
many of the tools the OpenEmbedded build system depends on,
such as |
|
14.21. |
How do I use an external toolchain? |
The toolchain configuration is very flexible and customizable.
It is primarily controlled with the
The default value of
In addition to the toolchain configuration, you also need a
corresponding toolchain recipe file.
This recipe file needs to package up any pre-built objects in
the toolchain such as |
|
14.22. |
How does the OpenEmbedded build system obtain source code and will it work behind my firewall or proxy server? |
The way the build system obtains source code is highly configurable. You can setup the build system to get source code in most environments if HTTP transport is available.
When the build system searches for source code, it first
tries the local download directory.
If that location fails, Poky tries
Assuming your distribution is "poky", the OpenEmbedded build
system uses the Yocto Project source
As an example, you could add a specific server for the
build system to attempt before any others by adding something
like the following to the PREMIRRORS_prepend = "\ git://.*/.* http://www.yoctoproject.org/sources/ \n \ ftp://.*/.* http://www.yoctoproject.org/sources/ \n \ http://.*/.* http://www.yoctoproject.org/sources/ \n \ https://.*/.* http://www.yoctoproject.org/sources/ \n"
These changes cause the build system to intercept Git, FTP,
HTTP, and HTTPS requests and direct them to the
Aside from the previous technique, these options also exist: BB_NO_NETWORK = "1" This statement tells BitBake to issue an error instead of trying to access the Internet. This technique is useful if you want to ensure code builds only from local sources. Here is another technique: BB_FETCH_PREMIRRORONLY = "1"
This statement limits the build system to pulling source
from the Here is another technique: BB_GENERATE_MIRROR_TARBALLS = "1" This statement tells the build system to generate mirror tarballs. This technique is useful if you want to create a mirror server. If not, however, the technique can simply waste time during the build.
Finally, consider an example where you are behind an
HTTP-only firewall.
You could make the following changes to the
PREMIRRORS_prepend = "\ ftp://.*/.* http://www.yoctoproject.org/sources/ \n \ http://.*/.* http://www.yoctoproject.org/sources/ \n \ https://.*/.* http://www.yoctoproject.org/sources/ \n" BB_FETCH_PREMIRRORONLY = "1"
These changes would cause the build system to successfully
fetch source over HTTP and any network accesses to anything
other than the
The build system also honors the standard shell environment
variables NoteYou can find more information on the "Working Behind a Network Proxy" Wiki page. |
|
14.23. |
Can I get rid of build output so I can start over? |
Yes - you can easily do this.
When you use BitBake to build an image, all the build output
goes into the directory created when you run the
build environment setup script (i.e.
Within the Build Directory, is the |
|
14.24. |
Why do |
Executables and libraries might need to be used from a directory other than the directory into which they were initially installed. Complicating this situation is the fact that sometimes these executables and libraries are compiled with the expectation of being run from that initial installation target directory. If this is the case, moving them causes problems.
This scenario is a fundamental problem for package maintainers
of mainstream Linux distributions as well as for the
OpenEmbedded build system.
As such, a well-established solution exists.
Makefiles, Autotools configuration scripts, and other build
systems are expected to respect environment variables such as
When the OpenEmbedded build system uses a recipe to build a
target-architecture program (i.e. one that is intended for
inclusion on the image being built), that program eventually
runs from the root file system of that image.
Thus, the build system provides a value of "/usr/bin" for
Meanwhile, NoteDue to these lengthy examples, the paths are artificially broken across lines for readability.
/home/maxtothemax/poky-bootchart2/build/tmp/work/i586-poky-linux/zlib/ 1.2.8-r0/sysroot-destdir/usr/bin /home/maxtothemax/poky-bootchart2/build/tmp/work/x86_64-linux/ zlib-native/1.2.8-r0/sysroot-destdir/home/maxtothemax/poky-bootchart2/ build/tmp/sysroots/x86_64-linux/usr/bin
Even if the paths look unusual, they both are correct -
the first for a target and the second for a native recipe.
These paths are a consequence of the
|
|
14.25. |
The files provided by my |
This situation results when a build system does
not recognize the environment variables supplied to it by
BitBake.
The incident that prompted this FAQ entry involved a Makefile
that used an environment variable named
|