| <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" |
| "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" |
| [<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] > |
| <!--SPDX-License-Identifier: CC-BY-2.0-UK--> |
| |
| <chapter id='faq'> |
| <title>FAQ</title> |
| <qandaset> |
| <qandaentry> |
| <question> |
| <para> |
| How does Poky differ from <ulink url='&OE_HOME_URL;'>OpenEmbedded</ulink>? |
| </para> |
| </question> |
| <answer> |
| <para> |
| The term "<link link='poky'>Poky</link>" |
| refers to the specific reference build system that |
| the Yocto Project provides. |
| Poky is based on <link linkend='oe-core'>OE-Core</link> |
| and <link linkend='bitbake-term'>BitBake</link>. |
| 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. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry> |
| <question> |
| <para id='faq-not-meeting-requirements'> |
| My development system does not meet the |
| required Git, tar, and Python versions. |
| In particular, I do not have Python 3.5.0 or greater. |
| Can I still use the Yocto Project? |
| </para> |
| </question> |
| <answer> |
| <para> |
| 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 |
| "<link linkend='required-git-tar-python-and-gcc-versions'>Required Git, tar, Python and gcc Versions</link>" |
| section for steps on how to update your build tools. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry> |
| <question> |
| <para> |
| How can you claim Poky / OpenEmbedded-Core is stable? |
| </para> |
| </question> |
| <answer> |
| <para> |
| There are three areas that help with stability; |
| <itemizedlist> |
| <listitem><para>The Yocto Project team keeps |
| <link linkend='oe-core'>OE-Core</link> small |
| and focused, containing around 830 recipes as opposed to the thousands |
| available in other OpenEmbedded community layers. |
| Keeping it small makes it easy to test and maintain.</para></listitem> |
| <listitem><para>The Yocto Project team runs manual and automated tests |
| using a small, fixed set of reference hardware as well as emulated |
| targets.</para></listitem> |
| <listitem><para>The Yocto Project uses an autobuilder, |
| which provides continuous build and integration tests.</para></listitem> |
| </itemizedlist> |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry> |
| <question> |
| <para> |
| How do I get support for my board added to the Yocto Project? |
| </para> |
| </question> |
| <answer> |
| <para> |
| 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 |
| "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and Creating Layers</ulink>" |
| section in the Yocto Project Development Tasks Manual and the |
| <ulink url='&YOCTO_DOCS_BSP_URL;'>Yocto Project Board Support Package (BSP) Developer's Guide</ulink>. |
| </para> |
| <para> |
| Usually, if the board is not completely exotic, adding support in |
| the Yocto Project is fairly straightforward. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry> |
| <question> |
| <para> |
| Are there any products built using the OpenEmbedded build system? |
| </para> |
| </question> |
| <answer> |
| <para> |
| The software running on the <ulink url='http://vernier.com/labquest/'>Vernier LabQuest</ulink> |
| is built using the OpenEmbedded build system. |
| See the <ulink url='http://www.vernier.com/products/interfaces/labq/'>Vernier LabQuest</ulink> |
| 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. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry> |
| <question> |
| <para> |
| What does the OpenEmbedded build system produce as output? |
| </para> |
| </question> |
| <answer> |
| <para> |
| 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. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry> |
| <question> |
| <para> |
| How do I add my package to the Yocto Project? |
| </para> |
| </question> |
| <answer> |
| <para> |
| To add a package, you need to create a BitBake recipe. |
| For information on how to create a BitBake recipe, see the |
| "<ulink url='&YOCTO_DOCS_DEV_URL;#new-recipe-writing-a-new-recipe'>Writing a New Recipe</ulink>" |
| section in the Yocto Project Development Tasks Manual. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry> |
| <question> |
| <para> |
| Do I have to reflash my entire board with a new Yocto Project image when recompiling |
| a package? |
| </para> |
| </question> |
| <answer> |
| <para> |
| The OpenEmbedded build system can build packages in various |
| formats such as IPK for OPKG, Debian package |
| (<filename>.deb</filename>), or RPM. |
| You can then upgrade the packages using the package tools on |
| the device, much like on a desktop distribution such as |
| Ubuntu or Fedora. |
| However, package management on the target is entirely optional. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry> |
| <question> |
| <para> |
| I see the error '<filename>chmod: XXXXX new permissions are r-xrwxrwx, not r-xr-xr-x</filename>'. |
| What is wrong? |
| </para> |
| </question> |
| <answer> |
| <para> |
| You are probably running the build on an NTFS filesystem. |
| Use <filename>ext2</filename>, <filename>ext3</filename>, or <filename>ext4</filename> instead. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <!-- <qandaentry> |
| <question> |
| <para> |
| How do I make the Yocto Project work in RHEL/CentOS? |
| </para> |
| </question> |
| <answer> |
| <para> |
| To get the Yocto Project working under RHEL/CentOS 5.1 you need to first |
| install some required packages. |
| The standard CentOS packages needed are: |
| <itemizedlist> |
| <listitem><para>"Development tools" (selected during installation)</para></listitem> |
| <listitem><para><filename>texi2html</filename></para></listitem> |
| <listitem><para><filename>compat-gcc-34</filename></para></listitem> |
| </itemizedlist> |
| On top of these, you need the following external packages: |
| <itemizedlist> |
| <listitem><para><filename>python-sqlite2</filename> from |
| <ulink url='http://dag.wieers.com/rpm/packages/python-sqlite2/'>DAG repository</ulink> |
| </para></listitem> |
| <listitem><para><filename>help2man</filename> from |
| <ulink url='http://centos.karan.org/el4/extras/stable/x86_64/RPMS/repodata/repoview/help2man-0-1.33.1-2.html'>Karan repository</ulink></para></listitem> |
| </itemizedlist> |
| </para> |
| |
| <para> |
| Once these packages are installed, the OpenEmbedded build system will be able |
| to build standard images. |
| However, there might be a problem with the QEMU emulator segfaulting. |
| You can either disable the generation of binary locales by setting |
| <filename><link linkend='var-ENABLE_BINARY_LOCALE_GENERATION'>ENABLE_BINARY_LOCALE_GENERATION</link> |
| </filename> to "0" or by removing the <filename>linux-2.6-execshield.patch</filename> |
| from the kernel and rebuilding it since that is the patch that causes the problems with QEMU. |
| </para> |
| |
| <note> |
| <para>For information on distributions that the Yocto Project |
| uses during validation, see the |
| <ulink url='&YOCTO_WIKI_URL;/wiki/Distribution_Support'>Distribution Support</ulink> |
| Wiki page.</para> |
| <para>For notes about using the Yocto Project on a RHEL 4-based |
| host, see the |
| <ulink url='&YOCTO_WIKI_URL;/wiki/BuildingOnRHEL4'>Building on RHEL4</ulink> |
| Wiki page.</para> |
| </note> |
| </answer> |
| </qandaentry> --> |
| |
| <qandaentry> |
| <question> |
| <para> |
| I see lots of 404 responses for files when the OpenEmbedded |
| build system is trying to download sources. |
| Is something wrong? |
| </para> |
| </question> |
| <answer> |
| <para> |
| 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. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry> |
| <question> |
| <para> |
| 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? |
| </para> |
| </question> |
| <answer> |
| <para> |
| Set <filename><link linkend='var-SRC_URI_OVERRIDES_PACKAGE_ARCH'>SRC_URI_OVERRIDES_PACKAGE_ARCH</link> |
| </filename> = "0" in the <filename>.bb</filename> file but make sure the package is |
| manually marked as |
| machine-specific for the case that needs it. |
| The code that handles |
| <filename>SRC_URI_OVERRIDES_PACKAGE_ARCH</filename> is in |
| the <filename>meta/classes/base.bbclass</filename> file. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry> |
| <question> |
| <para id='i-am-behind-a-firewall-and-need-to-use-a-proxy-server'> |
| I'm behind a firewall and need to use a proxy server. How do I do that? |
| </para> |
| </question> |
| <answer> |
| <para> |
| Most source fetching by the OpenEmbedded build system is done |
| by <filename>wget</filename> and you therefore need to specify |
| the proxy settings in a <filename>.wgetrc</filename> file, |
| which can be in your home directory if you are a single user |
| or can be in <filename>/usr/local/etc/wgetrc</filename> as |
| a global user file. |
| </para> |
| |
| <para> |
| Following is the applicable code for setting various proxy |
| types in the <filename>.wgetrc</filename> file. |
| By default, these settings are disabled with comments. |
| To use them, remove the comments: |
| <literallayout class='monospaced'> |
| # 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 |
| </literallayout> |
| The Yocto Project also includes a |
| <filename>meta-poky/conf/site.conf.sample</filename> file that |
| shows how to configure CVS and Git proxy servers if needed. |
| For more information on setting up various proxy types and |
| configuring proxy servers, see the |
| "<ulink url='&YOCTO_WIKI_URL;/wiki/Working_Behind_a_Network_Proxy'>Working Behind a Network Proxy</ulink>" |
| Wiki page. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry> |
| <question> |
| <para> |
| What's the difference between <replaceable>target</replaceable> and <replaceable>target</replaceable><filename>-native</filename>? |
| </para> |
| </question> |
| <answer> |
| <para> |
| The <filename>*-native</filename> targets are designed to run on the system |
| being used for the build. |
| These are usually tools that are needed to assist the build in some way such as |
| <filename>quilt-native</filename>, which is used to apply patches. |
| The non-native version is the one that runs on the target device. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry> |
| <question> |
| <para> |
| I'm seeing random build failures. Help?! |
| </para> |
| </question> |
| <answer> |
| <para> |
| If the same build is failing in totally different and random |
| ways, the most likely explanation is: |
| <itemizedlist> |
| <listitem><para>The hardware you are running the build on |
| has some problem.</para></listitem> |
| <listitem><para>You are running the build under |
| virtualization, in which case the virtualization |
| probably has bugs.</para></listitem> |
| </itemizedlist> |
| 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. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry> |
| <question> |
| <para> |
| When I try to build a native recipe, the build fails with <filename>iconv.h</filename> problems. |
| </para> |
| </question> |
| <answer> |
| <para> |
| If you get an error message that indicates GNU |
| <filename>libiconv</filename> is not in use but |
| <filename>iconv.h</filename> has been included from |
| <filename>libiconv</filename>, you need to check to see if |
| you have a previously installed version of the header file |
| in <filename>/usr/local/include</filename>. |
| <literallayout class='monospaced'> |
| #error GNU libiconv not in use but included iconv.h is from libiconv |
| </literallayout> |
| If you find a previously installed file, you should either |
| uninstall it or temporarily rename it and try the build again. |
| </para> |
| |
| <para> |
| 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 |
| <filename>iconv.h</filename>. |
| Be sure that leakage cannot occur from |
| <filename>/usr/local/include</filename> and |
| <filename>/opt</filename> locations. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry> |
| <question> |
| <para> |
| What do we need to ship for license compliance? |
| </para> |
| </question> |
| <answer> |
| <para> |
| 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. |
| </para> |
| |
| <para> |
| You can find more information on licensing in the |
| "<ulink url='&YOCTO_DOCS_OM_URL;#licensing'>Licensing</ulink>" |
| section in the Yocto Project Overview and Concepts Manual |
| and also in the |
| "<ulink url='&YOCTO_DOCS_DEV_URL;#maintaining-open-source-license-compliance-during-your-products-lifecycle'>Maintaining Open Source License Compliance During Your Product's Lifecycle</ulink>" |
| section in the Yocto Project Development Tasks Manual. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry> |
| <question> |
| <para> |
| How do I disable the cursor on my touchscreen device? |
| </para> |
| </question> |
| <answer> |
| <para> |
| You need to create a form factor file as described in the |
| "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-filelayout-misc-recipes'>Miscellaneous BSP-Specific Recipe Files</ulink>" |
| section in the Yocto Project Board Support Packages (BSP) |
| Developer's Guide. |
| Set the <filename>HAVE_TOUCHSCREEN</filename> variable equal to |
| one as follows: |
| <literallayout class='monospaced'> |
| HAVE_TOUCHSCREEN=1 |
| </literallayout> |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry> |
| <question> |
| <para> |
| How do I make sure connected network interfaces are brought up by default? |
| </para> |
| </question> |
| <answer> |
| <para> |
| 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 "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-filelayout-misc-recipes'>Miscellaneous BSP-Specific Recipe Files</ulink>" |
| section in the Yocto Project Board Support Packages (BSP) |
| Developer's Guide for information on creating these types of |
| miscellaneous recipe files. |
| </para> |
| <para> |
| For example, add the following files to your layer: |
| <literallayout class='monospaced'> |
| meta-MACHINE/recipes-bsp/netbase/netbase/MACHINE/interfaces |
| meta-MACHINE/recipes-bsp/netbase/netbase_5.0.bbappend |
| </literallayout> |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry> |
| <question> |
| <para> |
| How do I create images with more free space? |
| </para> |
| </question> |
| <answer> |
| <para> |
| 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: |
| <itemizedlist> |
| <listitem><para><emphasis>Image Size:</emphasis> |
| The OpenEmbedded build system uses the |
| <link linkend='var-IMAGE_ROOTFS_SIZE'><filename>IMAGE_ROOTFS_SIZE</filename></link> |
| variable to define the size of the image in Kbytes. |
| The build system determines the size by taking into |
| account the initial root filesystem size before any |
| modifications such as requested size for the image and |
| any requested additional free disk space to be |
| added to the image.</para></listitem> |
| <listitem><para><emphasis>Overhead:</emphasis> |
| Use the |
| <link linkend='var-IMAGE_OVERHEAD_FACTOR'><filename>IMAGE_OVERHEAD_FACTOR</filename></link> |
| variable to define the multiplier that the build system |
| applies to the initial image size, which is 1.3 by |
| default.</para></listitem> |
| <listitem><para><emphasis>Additional Free Space:</emphasis> |
| Use the |
| <link linkend='var-IMAGE_ROOTFS_EXTRA_SPACE'><filename>IMAGE_ROOTFS_EXTRA_SPACE</filename></link> |
| variable to add additional free space to the image. |
| The build system adds this space to the image after |
| it determines its |
| <filename>IMAGE_ROOTFS_SIZE</filename>. |
| </para></listitem> |
| </itemizedlist> |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry> |
| <question> |
| <para> |
| Why don't you support directories with spaces in the pathnames? |
| </para> |
| </question> |
| <answer> |
| <para> |
| The Yocto Project team has tried to do this before but too |
| many of the tools the OpenEmbedded build system depends on, |
| such as <filename>autoconf</filename>, break when they find |
| spaces in pathnames. |
| Until that situation changes, the team will not support spaces |
| in pathnames. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry> |
| <question> |
| <para> |
| How do I use an external toolchain? |
| </para> |
| </question> |
| <answer> |
| <para> |
| The toolchain configuration is very flexible and customizable. |
| It is primarily controlled with the |
| <filename><link linkend='var-TCMODE'>TCMODE</link></filename> |
| variable. |
| This variable controls which <filename>tcmode-*.inc</filename> |
| file to include from the |
| <filename>meta/conf/distro/include</filename> directory within |
| the |
| <link linkend='source-directory'>Source Directory</link>. |
| </para> |
| |
| <para> |
| The default value of <filename>TCMODE</filename> is "default", |
| which tells the OpenEmbedded build system to use its internally |
| built toolchain (i.e. <filename>tcmode-default.inc</filename>). |
| However, other patterns are accepted. |
| In particular, "external-*" refers to external toolchains. |
| One example is the Sourcery G++ Toolchain. |
| The support for this toolchain resides in the separate |
| <filename>meta-sourcery</filename> layer at |
| <ulink url='http://github.com/MentorEmbedded/meta-sourcery/'></ulink>. |
| </para> |
| |
| <para> |
| 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 <filename>libgcc</filename>, |
| <filename>libstdcc++</filename>, any locales, and |
| <filename>libc</filename>. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry> |
| <question> |
| <para id='how-does-the-yocto-project-obtain-source-code-and-will-it-work-behind-my-firewall-or-proxy-server'> |
| How does the OpenEmbedded build system obtain source code and |
| will it work behind my firewall or proxy server? |
| </para> |
| </question> |
| <answer> |
| <para> |
| 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. |
| </para> |
| <para> |
| When the build system searches for source code, it first |
| tries the local download directory. |
| If that location fails, Poky tries |
| <link linkend='var-PREMIRRORS'><filename>PREMIRRORS</filename></link>, |
| the upstream source, and then |
| <link linkend='var-MIRRORS'><filename>MIRRORS</filename></link> |
| in that order. |
| </para> |
| <para> |
| Assuming your distribution is "poky", the OpenEmbedded build |
| system uses the Yocto Project source |
| <filename>PREMIRRORS</filename> by default for SCM-based |
| sources, upstreams for normal tarballs, and then falls back |
| to a number of other mirrors including the Yocto Project |
| source mirror if those fail. |
| </para> |
| <para> |
| 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 <filename>local.conf</filename> |
| configuration file: |
| <literallayout class='monospaced'> |
| 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" |
| </literallayout> |
| </para> |
| <para> |
| These changes cause the build system to intercept Git, FTP, |
| HTTP, and HTTPS requests and direct them to the |
| <filename>http://</filename> sources mirror. |
| You can use <filename>file://</filename> URLs to point to |
| local directories or network shares as well. |
| </para> |
| <para> |
| Aside from the previous technique, these options also exist: |
| <literallayout class='monospaced'> |
| BB_NO_NETWORK = "1" |
| </literallayout> |
| 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. |
| </para> |
| <para> |
| Here is another technique: |
| <literallayout class='monospaced'> |
| BB_FETCH_PREMIRRORONLY = "1" |
| </literallayout> |
| This statement limits the build system to pulling source |
| from the <filename>PREMIRRORS</filename> only. |
| Again, this technique is useful for reproducing builds. |
| </para> |
| <para> |
| Here is another technique: |
| <literallayout class='monospaced'> |
| BB_GENERATE_MIRROR_TARBALLS = "1" |
| </literallayout> |
| 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. |
| </para> |
| <para> |
| Finally, consider an example where you are behind an |
| HTTP-only firewall. |
| You could make the following changes to the |
| <filename>local.conf</filename> configuration file as long as |
| the <filename>PREMIRRORS</filename> server is current: |
| <literallayout class='monospaced'> |
| 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" |
| </literallayout> |
| These changes would cause the build system to successfully |
| fetch source over HTTP and any network accesses to anything |
| other than the <filename>PREMIRRORS</filename> would fail. |
| </para> |
| <para> |
| The build system also honors the standard shell environment |
| variables <filename>http_proxy</filename>, |
| <filename>ftp_proxy</filename>, |
| <filename>https_proxy</filename>, and |
| <filename>all_proxy</filename> to redirect requests through |
| proxy servers. |
| </para> |
| <note> |
| You can find more information on the |
| "<ulink url='&YOCTO_WIKI_URL;/wiki/Working_Behind_a_Network_Proxy'>Working Behind a Network Proxy</ulink>" |
| Wiki page. |
| </note> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry> |
| <question> |
| <para> |
| Can I get rid of build output so I can start over? |
| </para> |
| </question> |
| <answer> |
| <para> |
| 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. |
| <link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>). |
| By default, this |
| <link linkend='build-directory'>Build Directory</link> |
| is named <filename>build</filename> but can be named |
| anything you want. |
| </para> |
| |
| <para> |
| Within the Build Directory, is the <filename>tmp</filename> |
| directory. |
| To remove all the build output yet preserve any source code or |
| downloaded files from previous builds, simply remove the |
| <filename>tmp</filename> directory. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry> |
| <question> |
| <para> |
| Why do <filename>${bindir}</filename> and <filename>${libdir}</filename> have strange values for <filename>-native</filename> recipes? |
| </para> |
| </question> |
| <answer> |
| <para> |
| 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. |
| </para> |
| |
| <para> |
| 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 |
| <filename>bindir</filename>, <filename>libdir</filename>, |
| and <filename>sysconfdir</filename> that indicate where |
| executables, libraries, and data reside when a program is |
| actually run. |
| They are also expected to respect a |
| <filename>DESTDIR</filename> environment variable, which is |
| prepended to all the other variables when the build system |
| actually installs the files. |
| It is understood that the program does not actually run from |
| within <filename>DESTDIR</filename>. |
| </para> |
| |
| <para> |
| 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 |
| <filename>bindir</filename>, a value of "/usr/lib" for |
| <filename>libdir</filename>, and so forth. |
| </para> |
| |
| <para> |
| Meanwhile, <filename>DESTDIR</filename> is a path within the |
| <link linkend='build-directory'>Build Directory</link>. |
| However, when the recipe builds a native program (i.e. one |
| that is intended to run on the build machine), that program |
| is never installed directly to the build machine's root |
| file system. |
| Consequently, the build system uses paths within the Build |
| Directory for <filename>DESTDIR</filename>, |
| <filename>bindir</filename> and related variables. |
| To better understand this, consider the following two paths |
| where the first is relatively normal and the second is not: |
| <note> |
| Due to these lengthy examples, the paths are artificially |
| broken across lines for readability. |
| </note> |
| <literallayout class='monospaced'> |
| /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 |
| </literallayout> |
| 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 |
| <filename>DESTDIR</filename> mechanism and while they |
| appear strange, they are correct and in practice very effective. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry> |
| <question> |
| <para> |
| The files provided by my <filename>*-native</filename> recipe do |
| not appear to be available to other recipes. |
| Files are missing from the native sysroot, my recipe is |
| installing to the wrong place, or I am getting permissions |
| errors during the do_install task in my recipe! What is wrong? |
| </para> |
| </question> |
| <answer> |
| <para> |
| This situation results when a build system does |
| not recognize the environment variables supplied to it by |
| <link linkend='bitbake-term'>BitBake</link>. |
| The incident that prompted this FAQ entry involved a Makefile |
| that used an environment variable named |
| <filename>BINDIR</filename> instead of the more standard |
| variable <filename>bindir</filename>. |
| The makefile's hardcoded default value of "/usr/bin" worked |
| most of the time, but not for the recipe's |
| <filename>-native</filename> variant. |
| For another example, permissions errors might be caused |
| by a Makefile that ignores <filename>DESTDIR</filename> or uses |
| a different name for that environment variable. |
| Check the the build system to see if these kinds of |
| issues exist. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| </qandaset> |
| </chapter> |
| <!-- |
| vim: expandtab tw=80 ts=4 |
| --> |