diff options
Diffstat (limited to 'import-layers/yocto-poky/documentation/ref-manual/faq.xml')
| -rw-r--r-- | import-layers/yocto-poky/documentation/ref-manual/faq.xml | 836 |
1 files changed, 836 insertions, 0 deletions
diff --git a/import-layers/yocto-poky/documentation/ref-manual/faq.xml b/import-layers/yocto-poky/documentation/ref-manual/faq.xml new file mode 100644 index 000000000..d2e4e8eb1 --- /dev/null +++ b/import-layers/yocto-poky/documentation/ref-manual/faq.xml @@ -0,0 +1,836 @@ +<!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; ] > + +<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 "<ulink url='&YOCTO_DOCS_DEV_URL;#poky'>Poky</ulink>" + refers to the specific reference build system that + the Yocto Project provides. + Poky is based on <ulink url='&YOCTO_DOCS_DEV_URL;#oe-core'>OE-Core</ulink> + and <ulink url='&YOCTO_DOCS_DEV_URL;#bitbake-term'>BitBake</ulink>. + 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 2.7.3 or greater, or + I do have Python 3.x, which is specifically not supported by + the Yocto Project. + 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-and-python-versions'>Required Git, tar, and Python 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 + <ulink url='&YOCTO_DOCS_DEV_URL;#oe-core'>OE-Core</ulink> 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 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>" + in the Yocto Project Development 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 on + <filename>&YOCTO_HOME_URL;/sources/*</filename>. 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_DEV_URL;#licensing'>Licensing</ulink>" + and "<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>" + sections, both of which are in the Yocto Project Development + 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 + <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>. + </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> + or + <link linkend='structure-memres-core-script'><filename>oe-init-build-env-memres</filename></link>). + By default, this <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink> + 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 + <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>. + 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 + <ulink url='&YOCTO_DOCS_DEV_URL;#bitbake-term'>BitBake</ulink>. + 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 +--> |
