Lines Matching full:the
8 beyond the surface of "how-to" information and reference (or look-up)
9 material. Concepts such as components, the :term:`OpenEmbedded Build System`
17 The :term:`BitBake` task executor
18 together with various types of configuration files form the
23 BitBake handles the parsing and execution of the data files. The data
32 decisions, and so forth. Configuration data acts as the glue to bind
36 to each data source as a layer. For information on layers, see the
38 section of the Yocto Project Development Tasks Manual.
42 see the
49 BitBake is the tool at the heart of the :term:`OpenEmbedded Build System`
51 for parsing the :term:`Metadata`, generating
55 BitBake, see the :doc:`BitBake User Manual <bitbake:index>`.
57 To see a list of the options BitBake supports, use either of the
63 The most common usage for BitBake is ``bitbake recipename``, where
64 ``recipename`` is the name of the recipe you want to build (referred
65 to as the "target"). The target often equates to the first part of a
67 So, to process the ``matchbox-desktop_1.2.3.bb`` recipe file, you might
68 type the following::
73 versions of ``matchbox-desktop`` might exist. BitBake chooses the one
74 selected by the distribution configuration. You can get more details
76 providers in the
78 of the BitBake User Manual.
84 A useful BitBake option to consider is the ``-k`` or ``--continue``
85 option. This option instructs BitBake to try and continue processing the
87 occurs, the target that failed and those that depend on it cannot be
94 Files that have the ``.bb`` suffix are "recipes" files. In general, a
96 information includes the location from which to download the unaltered
98 which special configuration options to apply, how to compile the source
99 files, and how to package the compiled output.
101 The term "package" is sometimes used to refer to recipes. However, since
102 the word "package" is used for the packaged output from the OpenEmbedded
104 using the term "package" when referring to recipes.
110 between recipes files. An example is the
113 The ":ref:`ref-manual/classes:Classes`" chapter in the
120 The configuration files (``.conf``) define various configuration
121 variables that govern the OpenEmbedded build process. These files fall
125 ``conf/local.conf``, which is found in the :term:`Build Directory`.
132 instructions) that tell the OpenEmbedded build system how to build a
133 target. :ref:`overview-manual/yp-intro:the yocto project layer model`
134 facilitates collaboration, sharing, customization, and reuse within the
137 all the configurations for a particular piece of hardware. Isolating
142 There are many layers working in the Yocto Project development environment. The
147 By convention, layers in the Yocto Project follow a specific form.
151 layers suitable for the Yocto Project in the
153 section of the Yocto Project Development Tasks Manual.
158 This section takes a more detailed look inside the build process used by
159 the :term:`OpenEmbedded Build System`,
160 which is the build
161 system specific to the Yocto Project. At the heart of the build system
162 is BitBake, the task executor.
164 The following diagram represents the high-level workflow of a build. The
165 remainder of this section expands on the fundamental input, output,
166 process, and metadata logical blocks that make up the workflow.
171 In general, the build's workflow consists of several functional areas:
173 - *User Configuration:* metadata you can use to control the build
181 - *Build System:* Processes under the control of
189 IPK), which are subsequently used in the construction of an image or
190 Software Development Kit (SDK), produced by the build system. These
195 - *Images:* Images produced by the workflow.
203 User configuration helps define the build. Through user configuration,
204 you can tell BitBake the target architecture for which you are building
205 the image, where to store downloaded source, and other build properties.
207 The following figure shows an expanded representation of the "User
208 Configuration" box of the :ref:`general workflow
215 build. These files are ``*.conf`` files. The minimally necessary ones
216 reside as example files in the ``build/conf`` directory of the
218 this section refers to the Source Directory as the "Poky Directory."
220 When you clone the :term:`Poky` Git repository
221 or you download and unpack a Yocto Project release, you can set up the
222 Source Directory to be named anything you want. For this discussion, the
223 cloned repository uses the default name ``poky``.
227 The Poky repository is primarily an aggregation of existing
230 The ``meta-poky`` layer inside Poky contains a ``conf`` directory that
233 :ref:`structure-core-script`, which is the
236 Sourcing the build environment script creates a
238 already exist. BitBake uses the Build Directory for all its work during
239 builds. The Build Directory has a ``conf`` directory that contains
242 if versions do not already exist in the Build Directory at the time you
243 source the build environment setup script.
245 Because the Poky repository is fundamentally an aggregation of existing
246 repositories, some users might be familiar with running the
247 :ref:`structure-core-script` script in the context of separate
250 assumes the script is executed from within a cloned or unpacked version
253 Depending on where the script is sourced, different sub-scripts are
254 called to set up the Build Directory (Yocto or OpenEmbedded).
255 Specifically, the script ``scripts/oe-setup-builddir`` inside the poky
256 directory sets up the Build Directory and seeds the directory (if
257 necessary) with configuration files appropriate for the Yocto Project
262 The
264 script uses the
268 The ``local.conf`` file provides many basic variables that define a
269 build environment. Here is a list of a few. To see the default
270 configurations in a ``local.conf`` file created by the build environment
271 script, see the
273 in the ``meta-poky`` layer:
275 - *Target Machine Selection:* Controlled by the
278 - *Download Directory:* Controlled by the
281 - *Shared State Directory:* Controlled by the
284 - *Build Output:* Controlled by the
287 - *Distribution Policy:* Controlled by the
290 - *Packaging Format:* Controlled by the
294 - *SDK Target Architecture:* Controlled by the
297 - *Extra Image Packages:* Controlled by the
303 Configurations set in the ``conf/local.conf`` file can also be set
304 in the ``conf/site.conf`` and ``conf/auto.conf`` configuration files.
306 The ``bblayers.conf`` file tells BitBake what layers you want considered
307 during the build. By default, the layers listed in this file include
308 layers minimally needed by the build system. However, you must manually
310 working with the ``bblayers.conf`` file in the
312 section in the Yocto Project Development Tasks Manual.
314 The files ``site.conf`` and ``auto.conf`` are not created by the
315 environment initialization script. If you want the ``site.conf`` file,
316 you need to create that yourself. The ``auto.conf`` file is typically
319 - *site.conf:* You can use the ``conf/site.conf`` configuration
323 example is perhaps the packaging format to use through the
327 One useful scenario for using the ``conf/site.conf`` file is to
329 to include the path to a ``conf/site.conf``. Then, when BitBake looks
330 for Metadata using :term:`BBPATH`, it finds the ``conf/site.conf`` file
331 and applies your common configurations found in the file. To override
332 configurations in a particular build directory, alter the similar
336 - *auto.conf:* The file is usually created and written to by an
337 autobuilder. The settings put into the file are typically the same as
338 you would find in the ``conf/local.conf`` or the ``conf/site.conf``
342 build environment. This process is represented by the "User
343 Configuration Edits" box in the figure.
345 When you launch your build with the ``bitbake target`` command, BitBake
346 sorts out the configurations to ultimately define your build
347 environment. It is important to understand that the
348 :term:`OpenEmbedded Build System` reads the
350 and ``local.conf``. And, the build system applies the normal assignment
351 statement rules as described in the
353 of the BitBake User Manual. Because the files are parsed in a specific
354 order, variable assignments for the same variable could be affected. For
355 example, if the ``auto.conf`` file and the ``local.conf`` set variable1
356 to different values, because the build system parses ``local.conf``
357 after ``auto.conf``, variable1 is assigned the value from the
363 The previous section described the user configurations that define
364 BitBake's global behavior. This section takes a closer look at the
365 layers the build system uses to further control the build. These layers
366 provide Metadata for the software, machine, and policies.
369 the "User Configuration" box in the `general workflow
374 of a software layer might be the :oe_layer:`meta-qt5 layer </meta-qt5>`
375 from the :oe_layerindex:`OpenEmbedded Layer Index <>`. This layer is for
376 version 5.0 of the popular `Qt <https://wiki.qt.io/About_Qt>`__
381 "BSP Layer" in the following figure) providing machine-specific
383 target architecture. A good example of a BSP layer from the
384 :ref:`overview-manual/yp-intro:reference distribution (poky)` is the
389 the following figure) providing top-level or general policies for the
391 example, in the Poky Reference Distribution the distro layer is the
393 layer. Within the distro layer is a ``conf/distro`` directory that
396 that contain many policy configurations for the Poky distribution.
398 The following figure shows an expanded representation of these three
399 layers from the :ref:`general workflow figure
406 licensing file (e.g. ``COPYING.MIT``) if the layer is to be distributed,
407 a ``README`` file as good practice and especially if the layer is to be
409 learn about the general structure for layers used with the Yocto Project
410 in the
412 section in the
414 layers and the many layers from which you can draw, see the
416 ":ref:`overview-manual/yp-intro:the yocto project layer model`" sections both
419 If you explored the previous links, you discovered some areas where many
420 layers that work with the Yocto Project exist. The :yocto_git:`Source
425 There are layers in the Yocto Project Source Repositories that cannot be
426 found in the OpenEmbedded Layer Index. Such layers are either
429 BitBake uses the ``conf/bblayers.conf`` file, which is part of the user
430 configuration, to find what layers it should be using as part of the
436 The distribution layer provides policy configurations for your
440 in your ``conf/local.conf`` file in the Build Directory.
442 The following list provides some explanation and references for what you
443 typically find in the distribution layer:
446 can be shared among recipes in the distribution. When your recipes
447 inherit a class, they take on the settings and functions for that
448 class. You can read more about class files in the
449 ":ref:`ref-manual/classes:Classes`" chapter of the Yocto
452 - *conf:* This area holds configuration files for the layer
453 (``conf/layer.conf``), the distribution
458 functionality across the distribution. This area could include
470 The BSP Layer provides machine configurations that target specific
471 hardware. Everything in this layer is specific to the machine for which
472 you are building the image or the SDK. A common structure or form is
473 defined for BSP layers. You can learn more about this structure in the
478 In order for a BSP layer to be considered compliant with the Yocto
481 The BSP Layer's configuration directory contains configuration files for
482 the machine (``conf/machine/machine.conf``) and, of course, the layer
485 The remainder of the layer is dedicated to specific recipes by function:
492 While the figure shows several
499 The software layer provides the Metadata for additional software
500 packages used during the build. This layer does not include Metadata
501 that is specific to the distribution or the machine, which are found in
510 In order for the OpenEmbedded build system to create an image or any
511 target, it must be able to access source files. The :ref:`general workflow
513 represents source files using the "Upstream Project Releases", "Local
514 Projects", and "SCMs (optional)" boxes. The figure represents mirrors,
515 which also play a role in locating source files, with the "Source
518 The method by which source files are ultimately organized is a function
519 of the project. For example, for released software, projects tend to use
520 tarballs or other archived files that can capture the state of a release
521 guaranteeing that it is statically represented. On the other hand, for a
525 control the point in the repository (the revision) from which you want
526 to build software. A combination of the two is also possible.
528 BitBake uses the :term:`SRC_URI`
530 recipe must have a :term:`SRC_URI` variable that points to the source.
533 from is pointed to by the
536 instruct the OpenEmbedded build system to create tarballs from Git
537 repositories, which is not the default behavior, and store them in the
538 :term:`DL_DIR` by using the
542 Judicious use of a :term:`DL_DIR` directory can save the build system a trip
543 across the Internet when looking for files. A good method for using a
545 your Build Directory. Doing so allows you to safely delete the Build
548 The remainder of this section provides a deeper look into the source
549 files and the mirrors. Here is a more detailed look at the source file
550 area of the :ref:`general workflow figure <overview-manual/concepts:openembedded build system conce…
558 Upstream project releases exist anywhere in the form of an archived file
560 recipes. For example, the figure uses specific releases each for
567 Local projects are custom bits of software the user provides. These bits
568 reside somewhere local to a project - perhaps a directory into which the
570 source tree used by the group).
572 The canonical method through which to include a local project is to use
573 the :ref:`externalsrc <ref-classes-externalsrc>`
574 class to include that local project. You use either the ``local.conf``
575 or a recipe's append file to override or set the recipe to point to the
576 local directory on your disk to pull in the whole source tree.
581 Another place from which the build system can get source files is with
584 repository is cloned or checked out. The
586 BitBake uses the :term:`SRC_URI`
587 variable and the argument's prefix to determine the correct fetcher
592 For information on how to have the OpenEmbedded build system generate
593 tarballs for Git repositories and place them in the
595 directory, see the :term:`BB_GENERATE_MIRROR_TARBALLS`
596 variable in the Yocto Project Reference Manual.
598 When fetching a repository, BitBake uses the
600 the specific revision from which to build.
605 There are two kinds of mirrors: pre-mirrors and regular mirrors. The
610 directory that is not a directory defined by the
615 Regular mirrors can be any site across the Internet that is used as an
616 alternative location for source code should the primary site not be
622 When the OpenEmbedded build system generates an image or an SDK, it gets
623 the packages from a package feed area located in the
624 :term:`Build Directory`. The :ref:`general workflow figure
626 shows this package feeds area in the upper-right corner.
628 This section looks a little closer into the package feeds area used by
629 the build system. Here is a more detailed look at the area:
634 Package feeds are an intermediary step in the build process. The
636 types, and you specify which classes to enable through the
638 variable. Before placing the packages into package feeds, the build
640 through the :ref:`insane <ref-classes-insane>`
643 The package feed area resides in the Build Directory. The directory the
645 combination of variables and the particular package manager in use. See
646 the "Package Feeds" box in the illustration and note the information to
647 the right of that area. In particular, the following defines where
651 ``tmp/deploy`` in the Build Directory.
653 - ``DEPLOY_DIR_*``: Depending on the package manager used, the package
655 creation, the
664 available for the i586 or qemux86 architectures.
666 BitBake uses the
668 tasks to generate packages and place them into the package holding area
669 (e.g. ``do_package_write_ipk`` for IPK packages). See the
675 sections in the Yocto Project Reference Manual for additional
678 i586 and qemux86. Packages for the i586 architecture are placed in
679 ``build/tmp/deploy/ipk/i586``, while packages for the qemux86
685 The OpenEmbedded build system uses
687 Software Development Kits (SDKs). You can see from the :ref:`general workflow
689 the BitBake area consists of several functional areas. This section takes a
694 Documentation for the BitBake tool is available separately. See the
701 The first stages of building a recipe are to fetch and unpack the source
707 The :ref:`ref-tasks-fetch` and
709 the source files and unpack them into the
718 statement, the OpenEmbedded build system takes a checksum of the file
719 for the recipe and inserts the checksum into the signature for the
721 task. If any local file has been modified, the
725 By default, everything is accomplished in the Build Directory, which has
726 a defined structure. For additional general information on the Build
727 Directory, see the ":ref:`structure-core-build`" section in
728 the Yocto Project Reference Manual.
730 Each recipe has an area in the Build Directory where the unpacked source
731 code resides. The :term:`S` variable points
732 to this area for a recipe's unpacked source code. The name of that
734 variables. The preceding figure and the following list describe the
737 - :term:`TMPDIR`: The base directory
738 where the OpenEmbedded build system performs all its work during the
739 build. The default base directory is the ``tmp`` directory.
741 - :term:`PACKAGE_ARCH`: The
742 architecture of the built package or packages. Depending on the
743 eventual destination of the package or packages (i.e. machine
745 specific machine), :term:`PACKAGE_ARCH` varies. See the variable's
748 - :term:`TARGET_OS`: The operating
749 system of the target device. A typical value would be "linux" (e.g.
752 - :term:`PN`: The name of the recipe used
753 to build the package. This variable can have multiple meanings.
754 However, when used in the context of input files, :term:`PN` represents
755 the name of the recipe.
757 - :term:`WORKDIR`: The location
758 where the OpenEmbedded build system builds a recipe (i.e. does the
759 work to create the package).
761 - :term:`PV`: The version of the
762 recipe used to build the package.
764 - :term:`PR`: The revision of the
765 recipe used to build the package.
767 - :term:`S`: Contains the unpacked source
770 - :term:`BPN`: The name of the recipe
771 used to build the package. The :term:`BPN` variable is a version of
772 the :term:`PN` variable but with common prefixes and suffixes removed.
774 - :term:`PV`: The version of the
775 recipe used to build the package.
779 In the previous figure, notice that there are two sample hierarchies:
782 The underlying structures are identical. The differentiator being
783 what the OpenEmbedded build system is using as a build target (e.g.
790 and applies them to the source files:
795 The :ref:`ref-tasks-patch` task uses a
797 and the :term:`FILESPATH` variable
800 Default processing for patch files assumes the files have either
802 to change the way the build system recognizes patch files. See the
806 BitBake finds and applies multiple patches for a single recipe in the
807 order in which it locates the patches. The :term:`FILESPATH` variable
808 defines the default set of directories that the build system uses to
809 search for patch files. Once found, patches are applied to the recipe's
810 source files, which are located in the
813 For more information on how the source directories are created, see the
815 more information on how to create patches and how the build system
816 processes patches, see the
818 section in the
819 Yocto Project Development Tasks Manual. You can also see the
820 ":ref:`sdk-manual/extensible:use \`\`devtool modify\`\` to modify the source of an existing compone…
821 section in the Yocto Project Application Development and the Extensible
822 Software Development Kit (SDK) manual and the
823 ":ref:`kernel-dev/common:using traditional kernel development to patch the kernel`"
824 section in the Yocto Project Linux Kernel Development Manual.
830 compile the source code. Once compilation occurs, the files are copied
836 This step in the build process consists of the following tasks:
839 This task sets up the two sysroots in
842 during the packaging phase the sysroots can contain the contents of
843 the
845 tasks of the recipes on which the recipe containing the tasks
846 depends. A sysroot exists for both the target and for the native
847 binaries, which run on the host system.
849 - *do_configure*: This task configures the source by enabling and
850 disabling any build-time and configuration options for the software
851 being built. Configurations can come from the recipe itself as well
852 as from an inherited class. Additionally, the software itself might
853 configure itself depending on the target for which it is being built.
855 The configurations handled by the
857 are specific to configurations for the source code being built by the
860 If you are using the
862 you can add additional configuration options by using the
866 class, see the
871 BitBake compiles the source using the
873 Compilation occurs in the directory pointed to by the
874 :term:`B` variable. Realize that the
875 :term:`B` directory is, by default, the same as the
878 - *do_install*: After compilation completes, BitBake executes the
880 This task copies files from the :term:`B` directory and places them in a
881 holding area pointed to by the :term:`D`
888 After source code is configured, compiled, and staged, the build system
889 analyzes the results and splits the output into packages:
894 The :ref:`ref-tasks-package` and
896 tasks combine to analyze the files found in the
898 subsets based on available packages and files. Analysis involves the
903 The ``do_packagedata`` task creates package metadata based on the
904 analysis such that the build system can generate the final packages. The
906 task stages (copies) a subset of the files installed by the
908 the appropriate sysroot. Working, staged, and intermediate results of
909 the analysis and package splitting process use several areas:
911 - :term:`PKGD`: The destination
916 temporary work area (i.e. ``pkgdata``) used by the ``do_package``
919 - :term:`PKGDEST`: The parent
925 the packaging process. The packaging process copies metadata from
926 :term:`PKGDESTWORK` to the :term:`PKGDATA_DIR` area where it becomes globally
930 The path for the sysroot for the system on which a component is built
934 The path for the sysroot used when building components for the build
938 The path for the sysroot used when a component that is built to
942 The :term:`FILES` variable defines the
948 Depending on the type of packages being created (RPM, DEB, or IPK), the
950 task creates the actual packages and places them in the Package Feed
951 area, which is ``${TMPDIR}/deploy``. You can see the
953 that part of the build process.
957 Support for creating feeds directly from the ``deploy/*``
959 kind of feed maintenance mechanism that would upload the new packages
960 into an official package feed (e.g. the Ångström distribution). This
962 provided out of the box.
967 Once packages are split and stored in the Package Feeds area, the build
968 system uses BitBake to generate the root filesystem image:
973 The image generation process consists of several stages and depends on
974 several tasks and variables. The
976 the root filesystem (file and directory structure) for an image. This
977 task uses several key variables to help create the list of packages to
981 out the base set of packages from which to install from the Package
985 Specifies packages that should not be installed into the image.
988 Specifies features to include in the image. Most of these features
992 Specifies the package backend (e.g. RPM, DEB, or IPK) to use and
993 consequently helps determine where to locate packages within the
997 Determines the language(s) for which additional language support
1001 The final list of packages passed to the package manager for
1002 installation into the image.
1005 pointing to the location of the filesystem under construction and the
1006 :term:`PACKAGE_INSTALL` variable providing the final list of packages to
1007 install, the root file system is created.
1009 Package installation is under control of the package manager (e.g.
1011 management is enabled for the target. At the end of the process, if
1012 package management is not enabled for the target, the package manager's
1013 data files are deleted from the root filesystem. As part of the final
1015 of the packages are run. Any scripts that fail to run on the build host
1016 are run on the target when the target system is first booted. If you are
1019 all the post installation scripts must succeed on the build host during
1020 the package installation phase since the root filesystem on the target
1023 The final stages of the ``do_rootfs`` task handle post processing. Post
1026 The manifest file (``.manifest``) resides in the same directory as the
1027 root filesystem image. This file lists out, line-by-line, the installed
1028 packages. The manifest file is useful for the
1030 for example, to determine whether or not to run specific tests. See the
1034 Optimizing processes that are run across the image include ``mklibs``
1035 and any other post-processing commands as defined by the
1037 variable. The ``mklibs`` process optimizes the size of the libraries.
1039 After the root filesystem is built, processing begins on the image
1040 through the :ref:`ref-tasks-image`
1041 task. The build system runs any pre-processing commands as defined by
1042 the
1044 variable. This variable specifies a list of functions to call before the
1045 build system creates the final image output files.
1047 The build system dynamically creates ``do_image_*`` tasks as needed,
1048 based on the image types specified in the
1050 The process turns everything into an image file or a set of image files
1051 and can compress the root filesystem image to reduce the overall size of
1052 the image. The formats used for the root filesystem depend on the
1053 :term:`IMAGE_FSTYPES` variable. Compression depends on whether the formats
1057 image type would take the following form::
1061 So, if the type
1062 as specified by the :term:`IMAGE_FSTYPES` were ``ext4``, the dynamically
1067 The final task involved in image creation is the
1069 task. This task completes the image by applying any image post
1070 processing as defined through the
1072 variable. The variable specifies a list of functions to call once the
1073 build system has created the final image output files.
1077 The entire image generation process is run under
1078 Pseudo. Running under Pseudo ensures that the files in the root filesystem
1084 The OpenEmbedded build system uses BitBake to generate the Software
1085 Development Kit (SDK) installer scripts for both the standard SDK and
1086 the extensible SDK (eSDK):
1093 For more information on the cross-development toolchain generation,
1094 see the ":ref:`overview-manual/concepts:cross-development toolchain generation`"
1096 cross-development toolchain using the do_populate_sdk task, see the
1098 the Yocto Project Application Development and the Extensible Software
1101 Like image generation, the SDK script process consists of several stages
1102 and depends on many variables. The
1106 tasks use these key variables to help create the list of packages to
1107 actually install. For information on the variables listed in the figure,
1108 see the ":ref:`overview-manual/concepts:application development sdk`"
1111 The ``do_populate_sdk`` task helps create the standard SDK and handles
1112 two parts: a target part and a host part. The target part is the part
1113 built for the target hardware and includes libraries and headers. The
1114 host part is the part of the SDK that runs on the
1117 The ``do_populate_sdk_ext`` task helps create the extensible SDK and
1119 the standard SDK. For the extensible SDK, the task encapsulates the
1120 build system, which includes everything needed (host and target) for the
1123 Regardless of the type of SDK being constructed, the tasks perform some
1125 needed configuration files are created. The final output is the
1127 includes the environment setup script.
1129 Stamp Files and the Rerunning of Tasks
1133 into the :term:`STAMPS_DIR`
1134 directory. The beginning of the stamp file's filename is determined by
1135 the :term:`STAMP` variable, and the end
1136 of the name consists of the task's name and current :ref:`input
1143 is "OEBasicHash", which is almost always the case in current
1147 with a matching input checksum exists for the task. In this case,
1148 the task's output is assumed to exist and still be valid. Otherwise,
1149 the task is rerun.
1153 The stamp mechanism is more general than the shared state (sstate)
1154 cache mechanism described in the
1157 tasks that can be accelerated through the sstate cache.
1161 output. The actual task output would usually be somewhere in
1164 the sstate cache mechanism adds is a way to cache task output that
1172 mark it with the :ref:`nostamp <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:variable f…
1176 For details on how to view information about a task's signature, see the
1178 section in the Yocto Project Development Tasks Manual.
1183 The description of tasks so far assumes that BitBake needs to build
1186 usually made available in the form of a shared state (sstate) cache.
1190 For information on variables affecting sstate, see the
1196 The idea of a setscene task (i.e ``do_taskname_setscene``) is a
1197 version of the task where instead of building something, BitBake can
1198 skip to the end result and simply place a set of files into specific
1200 task variant (e.g. generating package files in the
1205 the work involved would be equal to or greater than the underlying task.
1207 In the build system, the common tasks that have setscene variants are
1213 Notice that these tasks represent most of the tasks whose output is an
1216 The build system has knowledge of the relationship between these tasks
1219 to run any of the ``do_fetch``, ``do_unpack``, ``do_patch``,
1226 to compile or patch. If the ``do_package_write_*`` packages are available
1227 from sstate, BitBake does not need the ``do_package`` task data.
1229 To handle all these complexities, BitBake runs in two phases. The first
1230 is the "setscene" stage. During this stage, BitBake first checks the
1232 fast check to see if the object exists rather than doing a complete download.
1233 If nothing exists, the second phase, which is the setscene stage,
1234 completes and the main build proceeds.
1236 If objects are found in the sstate cache, the build system works
1237 backwards from the end targets specified by the user. For example, if an
1238 image is being built, the build system first looks for the packages
1239 needed for that image and the tools needed to construct an image. If
1240 those are available, the compiler is not needed. Thus, the compiler is
1241 not even downloaded. If something was found to be unavailable, or the
1242 download or setscene task fails, the build system then tries to install
1243 dependencies, such as the compiler, from the cache.
1245 The availability of objects in the sstate cache is handled by the
1246 function specified by the :term:`BB_HASHCHECK_FUNCTION`
1247 variable and returns a list of available objects. The function specified
1248 by the :term:`BB_SETSCENE_DEPVALID`
1249 variable is the function that determines whether a given dependency
1250 needs to be followed, and whether for any given relationship the
1251 function needs to be passed. The function returns a True or False value.
1256 The images produced by the build system are compressed forms of the root
1258 the :ref:`general workflow figure
1268 For a list of example images that the Yocto Project provides, see the
1269 ":doc:`/ref-manual/images`" chapter in the Yocto Project Reference
1272 The build process writes images out to the :term:`Build Directory`
1273 inside the
1274 ``tmp/deploy/images/machine/`` folder as shown in the figure. This
1275 folder contains any files expected to be loaded on the target device.
1276 The :term:`DEPLOY_DIR` variable
1277 points to the ``deploy`` directory, while the
1279 variable points to the appropriate directory containing images for the
1282 - kernel-image: A kernel binary file. The
1284 variable determines the naming scheme for the kernel image file.
1285 Depending on this variable, the file could begin with a variety of
1286 naming strings. The ``deploy/images/``\ machine directory can contain
1287 multiple image files for the machine.
1289 - root-filesystem-image: Root filesystems for the target device (e.g.
1290 ``*.ext3`` or ``*.bz2`` files). The
1292 variable determines the root filesystem image type. The
1294 filesystems for the machine.
1296 - kernel-modules: Tarballs that contain all the modules built for the
1298 suppressed by setting the
1300 variable to "0". The ``deploy/images/``\ machine directory can
1301 contain multiple kernel module tarballs for the machine.
1303 - bootloaders: If applicable to the target machine, bootloaders
1304 supporting the image. The ``deploy/images/``\ machine directory can
1305 contain multiple bootloaders for the machine.
1307 - symlinks: The ``deploy/images/``\ machine folder contains a symbolic
1308 link that points to the most recently built file for each machine.
1310 the latest version of each file.
1315 In the :ref:`general workflow figure
1316 <overview-manual/concepts:openembedded build system concepts>`, the
1317 output labeled "Application Development SDK" represents an SDK. The SDK
1326 The specific form of this output is a set of files that includes a
1328 files, and files used for SDK testing. When the SDK installer file is
1329 run, it installs the SDK. The SDK consists of a cross-development
1332 cross-development environment. You can think of the cross-toolchain as
1333 the "host" part because it runs on the SDK machine. You can think of the
1334 libraries and headers as the "target" part because they are built for
1335 the target hardware. The environment setup script is added so that you
1336 can initialize the environment before using the tools.
1340 - The Yocto Project supports several methods by which you can set up
1345 - For background information on cross-development toolchains in the
1346 Yocto Project development environment, see the
1351 the :doc:`/sdk-manual/index` manual.
1353 All the output files for an SDK are written to the ``deploy/sdk`` folder
1354 inside the :term:`Build Directory` as
1355 shown in the previous figure. Depending on the type of SDK, there are
1356 several variables to configure these files. Here are the variables
1360 the ``deploy`` directory.
1363 Controls whether or not shared state artifacts are copied into the
1365 copied into the SDK.
1368 Specifies whether or not packagedata is included in the extensible
1369 SDK for all recipes in the "world" target.
1372 Specifies whether or not the toolchain is included when building the
1376 A list of variables allowed through from the build system
1377 configuration into the extensible SDK configuration.
1380 A list of variables not allowed through from the build system
1381 configuration into the extensible SDK configuration.
1384 A list of classes to remove from the
1386 within the extensible SDK configuration.
1388 This next list, shows the variables associated with a standard SDK:
1391 the ``deploy`` directory.
1394 the architecture of the machine on which the cross-development tools
1395 are run to create packages for the target hardware.
1398 Lists the features to include in the "target" part of the SDK.
1401 Lists packages that make up the host part of the SDK (i.e. the part
1402 that runs on the :term:`SDKMACHINE`). When you use
1403 ``bitbake -c populate_sdk imagename`` to create the SDK, a set of
1408 Lists packages that make up the target part of the SDK (i.e. the part
1409 built for the target hardware).
1411 - :term:`SDKPATH`: Defines the
1412 default SDK installation path offered by the installation script.
1415 Lists all the installed packages that make up the host part of the
1417 development as well. However, it is mainly used for the standard SDK.
1420 Lists all the installed packages that make up the target part of the
1422 development as well. However, it is mainly used for the standard SDK.
1427 The Yocto Project does most of the work for you when it comes to
1428 creating :ref:`sdk-manual/intro:the cross-development toolchain`. This
1431 can also see the :doc:`/sdk-manual/index` manual.
1433 In the Yocto Project development environment, cross-development
1434 toolchains are used to build images and applications that run on the
1435 target hardware. With just a few commands, the OpenEmbedded build system
1438 The following figure shows a high-level build environment regarding
1444 Most of the work occurs on the Build Host. This is the machine used to
1445 build images and generally work within the the Yocto Project
1447 :term:`BitBake` to create an image, the
1448 OpenEmbedded build system uses the host ``gcc`` compiler to bootstrap a
1449 cross-compiler named ``gcc-cross``. The ``gcc-cross`` compiler is what
1450 BitBake uses to compile source files when creating the target image. You
1456 The extensible SDK does not use ``gcc-cross-canadian``
1457 since this SDK ships a copy of the OpenEmbedded build system and the
1460 The chain of events that occurs when the standard toolchain is bootstrapped::
1464 - ``gcc``: The compiler, GNU Compiler Collection (GCC).
1466 - ``binutils-cross``: The binary utilities needed in order
1467 to run the ``gcc-cross`` phase of the bootstrap operation and build the
1468 headers for the C library.
1470 - ``linux-libc-headers``: Headers needed for the cross-compiler and C library build.
1472 - ``libgcc-initial``: An initial version of the gcc support library needed
1475 - ``libgcc``: The final version of the gcc support library which
1478 - ``glibc``: The GNU C Library.
1480 - ``gcc-cross``: The final stage of the bootstrap process for the
1481 cross-compiler. This stage results in the actual cross-compiler that
1485 the build host).
1487 - ``gcc-runtime``: Runtime libraries resulting from the toolchain
1489 the runtime libraries need for the targeted device.
1491 You can use the OpenEmbedded build system to build an installer for the
1492 relocatable SDK used to develop applications. When you run the
1493 installer, it installs the toolchain, which contains the development
1495 other ``nativesdk-*`` tools), which are tools native to the SDK (i.e.
1497 need to cross-compile and test your software. The figure shows the
1499 cross-development toolchain is built to execute on the
1501 might not be the same machine as the Build Host.
1505 If your target architecture is supported by the Yocto Project, you
1506 can take advantage of pre-built images that ship with the Yocto
1509 Here is the bootstrap process for the relocatable toolchain::
1513 - ``gcc``: The build host's GNU Compiler Collection (GCC).
1515 - ``binutils-crosssdk``: The bare minimum binary utilities needed in
1516 order to run the ``gcc-crosssdk-initial`` phase of the bootstrap
1519 - ``gcc-crosssdk-initial``: An early stage of the bootstrap process for
1520 creating the cross-compiler. This stage builds enough of the
1521 ``gcc-crosssdk`` and supporting pieces so that the final stage of the
1522 bootstrap process can produce the finished cross-compiler. This tool
1523 is a "native" binary that runs on the build host.
1525 - ``linux-libc-headers``: Headers needed for the cross-compiler.
1527 - ``glibc-initial``: An initial version of the Embedded GLIBC needed to
1530 - ``nativesdk-glibc``: The Embedded GLIBC needed to bootstrap the
1533 - ``gcc-crosssdk``: The final stage of the bootstrap process for the
1534 relocatable cross-compiler. The ``gcc-crosssdk`` is a transitory
1535 compiler and never leaves the build host. Its purpose is to help in
1536 the bootstrap process to create the eventual ``gcc-cross-canadian``
1538 (i.e. it is designed to run on the build host).
1540 - ``gcc-cross-canadian``: The final relocatable cross-compiler. When
1541 run on the :term:`SDKMACHINE`,
1542 this tool produces executable code that runs on the target device.
1545 configurations passed to the compiler through the compile commands.
1546 This circumvents the need for multiple compilers and thus reduces the
1547 size of the toolchains.
1552 cross-development toolchain installer, see the
1554 in the Yocto Project Application Development and the
1560 By design, the OpenEmbedded build system builds everything from scratch
1566 scratch so they have a known state from the start.
1569 to the process. As mentioned in the previous paragraph, building from
1575 The Yocto Project implements shared state code that supports incremental
1576 builds. The implementation of the shared state code answers the
1577 following questions that were fundamental roadblocks within the
1580 - What pieces of the system have changed and what pieces have not
1588 For the first question, the build system detects changes in the "inputs"
1589 to a given task by creating a checksum (or signature) of the task's
1590 inputs. If the checksum changes, the system assumes the inputs have
1591 changed and the task needs to be rerun. For the second question, the
1592 shared state (sstate) code tracks which tasks add which output to the
1593 build process. This means the output from a given task can be removed,
1594 upgraded or otherwise manipulated. The third question is partly
1595 addressed by the solution for the second question assuming the build
1596 system can fetch the sstate objects from remote locations and install
1601 - The build system does not maintain
1603 the shared state packages. Consequently, there are considerations that
1604 affect maintaining shared state feeds. For information on how the
1606 …information, see the ":ref:`dev-manual/common-tasks:automatically incrementing a package version n…
1607 section in the Yocto Project Development Tasks Manual.
1609 - The code in the build system that supports incremental builds is
1611 related to shared state code, see the
1612 …":ref:`dev-manual/common-tasks:viewing metadata used to create the input signature of a shared sta…
1615 sections both in the Yocto Project Development Tasks Manual.
1617 The rest of this section goes into detail about the overall incremental
1618 build architecture, the checksums (signatures), and shared state.
1623 When determining what parts of the system need to be built, BitBake
1626 To help explain, consider having the IPK packaging backend enabled and
1627 then switching to DEB. In this case, the
1630 are still valid. However, with a per-recipe approach, the build would
1631 not include the ``.deb`` files. Consequently, you would have to
1632 invalidate the whole build and rerun it. Rerunning everything is not the
1633 best solution. Also, in this case, the core must be "taught" much about
1636 touching the packaged-staging core.
1641 The shared state code uses a checksum, which is a unique signature of a
1643 is a change in a task's inputs that triggers a rerun, the process needs
1644 to detect all the inputs to a given task. For shell tasks, this turns
1645 out to be fairly easy because the build process generates a "run" shell
1647 you a good idea of when the task's data changes.
1649 To complicate the problem, there are things that should not be included
1650 in the checksum. First, there is the actual specific build path of a
1651 given task - the :term:`WORKDIR`. It
1652 does not matter if the work directory changes because it should not
1653 affect the output for target packages. Also, the build process has the
1658 Both native and cross packages run on the
1659 build host. However, cross packages generate output for the target
1662 The checksum therefore needs to exclude :term:`WORKDIR`. The simplistic
1663 approach for excluding the work directory is to set :term:`WORKDIR` to some
1664 fixed value and create the checksum for the "run" script.
1666 Another problem results from the "run" scripts containing functions that
1667 might or might not get called. The incremental build solution contains
1669 used to prune the "run" scripts down to the minimum set, thereby
1670 alleviating this problem and making the "run" scripts much more readable
1673 So far, there are solutions for shell scripts. What about Python tasks? The
1674 same approach applies even though these tasks are more difficult. The
1676 and what functions it calls. Again, the incremental build solution
1677 contains code that first figures out the variable and function
1678 dependencies, and then creates a checksum for the data used as the input
1679 to the task.
1681 Like the :term:`WORKDIR` case, there can be situations where dependencies should be
1682 ignored. For these situations, you can instruct the build process to
1683 ignore a dependency by using a line like the following::
1687 This example ensures that the :term:`PACKAGE_ARCHS` variable
1688 does not depend on the value of :term:`MACHINE`, even if it does
1692 not able to find. You can accomplish this by using a line like the
1698 adds the :term:`MACHINE` variable as a dependency for :term:`PACKAGE_ARCHS`.
1703 it cannot figure out dependencies. The Yocto Project team has currently
1704 not managed to cover those dependencies in detail and is aware of the
1707 Thus far, this section has limited discussion to the direct inputs into
1708 a task. Information based on direct inputs is referred to as the
1709 "basehash" in the code. However, the question of a task's indirect
1710 inputs still exits - items already built and present in the
1711 :term:`Build Directory`. The checksum (or
1712 signature) for a particular task needs to add the hashes of all the
1713 tasks on which the particular task depends. Choosing which dependencies
1714 to add is a policy decision. However, the effect is to generate a
1715 checksum that combines the basehash and the hashes of the task's
1718 At the code level, there are multiple ways by which both the basehash
1719 and the dependent task hashes can be influenced. Within the BitBake
1721 it construct the basehash. The following statement effectively results
1731 The previous example does not include :term:`WORKDIR` since that variable is
1734 The rules for deciding which hashes of dependent tasks to include
1736 accomplished with a Python function. The code in
1738 illustrates how you can insert your own policy into the system if so
1739 desired. This file defines the two basic signature generators
1743 versions. OE-Core uses the "OEBasicHash" signature handler by default
1744 through this setting in the ``bitbake.conf`` file::
1748 The "OEBasicHash" :term:`BB_SIGNATURE_HANDLER` is the same
1749 as the "OEBasic" version but adds the task hash to the :ref:`stamp
1750 files <overview-manual/concepts:stamp files and the rerunning of tasks>`. This
1751 results in any metadata change that changes the task hash, automatically causing
1752 the task to be run again. This removes the need to bump
1754 automatically ripple across the build.
1756 It is also worth noting that the end result of these signature
1758 the build. This information includes:
1760 - ``BB_BASEHASH:task-``\ taskname: The base hashes for each task in the
1763 - ``BB_BASEHASH_``\ filename\ ``:``\ taskname: The base hashes for each
1766 - :term:`BB_TASKHASH`: The hash of the currently running task.
1771 Checksums and dependencies, as discussed in the previous section, solve
1772 half the problem of supporting a shared state. The other half of the
1773 problem is being able to use checksum information during the build and
1776 The :ref:`sstate <ref-classes-sstate>` class is a
1778 given task. The idea is that the build process does not care about the
1780 downloaded and unpacked from somewhere. In other words, the build
1785 the output of either
1787 :ref:`ref-tasks-package`. The other
1789 directory tree such as the sysroot.
1791 The Yocto Project team has tried to keep the details of the
1792 implementation hidden in the :ref:`sstate <ref-classes-sstate>` class. From a user's perspective,
1795 from the :ref:`deploy <ref-classes-deploy>` class::
1809 The following list explains the previous example:
1812 sstate-related processing, which is implemented in the
1814 before and after the
1817 - The ``do_deploy[sstate-inputdirs] = "${DEPLOYDIR}"`` declares that
1819 (i.e. when not using the sstate cache). This output becomes the input
1820 to the shared state cache.
1822 - The ``do_deploy[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}"`` line
1823 causes the contents of the shared state cache to be copied to
1828 If ``do_deploy`` is not already in the shared state cache or if its input
1829 checksum (signature) has changed from when the output was cached, the task
1830 runs to populate the shared state cache, after which the contents of the
1832 ``do_deploy`` is in the shared state cache and its signature indicates
1833 that the cached output is still valid (i.e. if no relevant task inputs
1834 have changed), then the contents of the shared state cache copies
1835 directly to ${:term:`DEPLOY_DIR_IMAGE`} by the ``do_deploy_setscene`` task
1836 instead, skipping the ``do_deploy`` task.
1838 - The following task definition is glue logic needed to make the
1846 ``sstate_setscene()`` takes the flags above as input and accelerates the ``do_deploy`` task
1847 through the shared state cache if possible. If the task was
1849 returns False, and the normal ``do_deploy`` task runs. For more
1850 information, see the ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-execution:setscene`"
1851 section in the BitBake User Manual.
1853 - The ``do_deploy[dirs] = "${DEPLOYDIR} ${B}"`` line creates
1854 ``${DEPLOYDIR}`` and ``${B}`` before the ``do_deploy`` task runs, and
1855 also sets the current working directory of ``do_deploy`` to ``${B}``.
1856 …For more information, see the ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:vari…
1857 section in the BitBake
1863 the same, you can use ``sstate-plaindirs``. For example, to preserve the
1864 ${:term:`PKGD`} and ${:term:`PKGDEST`} output from the ``do_package``
1865 task, use the following::
1870 - The ``do_deploy[stamp-extra-info] = "${MACHINE_ARCH}"`` line appends
1871 extra metadata to the :ref:`stamp
1872 file <overview-manual/concepts:stamp files and the rerunning of tasks>`. In
1873 this case, the metadata makes the task specific to a machine's architecture.
1875 ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-execution:the task list`"
1876 section in the BitBake User Manual for more information on the
1880 multiple directories. For example, the following declares
1882 which populates the shared state cache, and :term:`PKGDATA_DIR` and
1883 ``SHLIBSDIR`` as the corresponding shared state output directories::
1888 - These methods also include the ability to take a lockfile when
1894 Behind the scenes, the shared state code works by looking in
1905 The shared state directory (:term:`SSTATE_DIR`) is organized into two-character
1906 subdirectories, where the subdirectory names are based on the first two
1907 characters of the hash.
1908 If the shared state directory structure for a mirror has the same structure
1909 as :term:`SSTATE_DIR`, you must specify "PATH" as part of the URI to enable the build
1910 system to map to the appropriate subdirectory.
1912 The shared state package validity can be detected just by looking at the
1913 filename since the filename contains the task checksum (or signature) as
1915 found, the build process downloads it and uses it to accelerate the
1918 The build processes use the ``*_setscene`` tasks for the task
1919 acceleration phase. BitBake goes through this phase before the main
1922 available, the shared state package is used. This means the task and any
1925 As a real world example, the aim is when building an IPK-based image,
1926 only the
1929 Since the sysroot is not used, it would never get extracted. This is
1931 recipe-based approach, which would have to install the output from every
1937 The above section explained how BitBake skips the execution of tasks
1938 whose output can already be found in the Shared State cache.
1940 During a build, it may often be the case that the output / result of a task might
1941 be unchanged despite changes in the task's input values. An example might be
1948 - The *task hash* explained earlier: computed from the recipe metadata,
1949 the task code and the task hash values from its dependencies.
1951 causing the task to re-execute. The task hashes of tasks depending on this
1952 task are therefore modified too, causing the whole dependency
1955 - The *output hash*, a new hash computed from the output of Shared State tasks,
1957 The mapping between the task hash and its output hash is reported
1959 by the server for future reference.
1961 - The *unihash*, a new hash, initially set to the task hash for the task.
1962 This is used to track the *unicity* of task output, and we will explain
1965 When Hash Equivalence is enabled, BitBake computes the task hash
1966 for each task by using the unihash of its dependencies, instead
1974 Then, the new mapping between the new task hash and its output hash
1975 will be reported to the Hash Equivalence server. The server will
1976 let BitBake know whether this output hash is the same as a previously
1979 If the output hash is already known, BitBake will update the task's
1980 unihash to match the original task hash that generated that output.
1981 Thanks to this, the depending tasks will keep a previously recorded
1983 the Shared State cache, instead of re-executing them. Similarly, the
1987 If the output hash is unknown, a new entry will be created on the Hash
1988 Equivalence server, matching the task hash to that output.
1989 The depending tasks, still having a new task hash because of the
1990 change, will need to re-execute as expected. The change propagates
1991 to the depending tasks.
1993 To summarize, when Hash Equivalence is enabled, a change in one of the
1994 tasks in BitBake's run queue doesn't have to propagate to all the
1995 downstream tasks that depend on the output of this task, causing a
1996 full rebuild of such tasks, and so on with the next depending tasks.
1997 Instead, when the output of this task remains identical to previously
1998 recorded output, BitBake can safely retrieve all the downstream
1999 task output from the Shared State cache.
2004 the stability of the task's output hash. Therefore, the effectiveness
2011 in the ordering of variables.
2014 For sure, the programs using such a library should be rebuilt, but
2015 their new binaries should remain identical. The corresponding tasks should
2016 have a different output hash because of the change in the hash of their
2018 Equivalence will stop the propagation down the dependency chain.
2020 - Native tool updates. Though the depending tasks should be rebuilt,
2021 it's likely that they will generate the same output and be marked
2031 allowing to connect the local server to an upstream one.
2035 Therefore, the default configuration in Poky corresponds to the
2048 The shared Hash Equivalence server needs to be maintained together with the
2049 Shared State cache. Otherwise, the server could report Shared State hashes
2057 See the :term:`BB_HASHSERVE` reference for details about starting
2060 See the `video <https://www.youtube.com/watch?v=zXEdqGS62Wc>`__
2063 presentation at ELC 2020 for a very synthetic introduction to the
2064 Hash Equivalence implementation in the Yocto Project.
2069 The OpenEmbedded build system automatically adds common types of runtime
2071 explicitly declare the packages using
2076 dependencies, you must manually declare the dependencies.
2078 - ``shlibdeps``: During the
2080 each recipe, all shared libraries installed by the recipe are
2081 located. For each shared library, the package that contains the
2082 shared library is registered as providing the shared library. More
2083 specifically, the package is registered as providing the
2084 `soname <https://en.wikipedia.org/wiki/Soname>`__ of the library. The
2086 :term:`PKGDATA_DIR` by the
2090 Simultaneously, all executables and shared libraries installed by the
2094 contains the shared library. If such a package is found, a runtime
2095 dependency is added from the package that depends on the shared
2096 library to the package that contains the library.
2098 The automatically added runtime dependency also includes a version
2099 restriction. This version restriction specifies that at least the
2100 current version of the package that provides the shared library must
2102 This forces an upgrade of the package containing the shared library
2103 when installing the package that depends on the library, if needed.
2106 particular shared library (e.g. because the library is for internal
2107 use only), then add the library to
2109 the package's recipe.
2111 - ``pcdeps``: During the ``do_package`` task of each recipe, all
2112 pkg-config modules (``*.pc`` files) installed by the recipe are
2113 located. For each module, the package that contains the module is
2114 registered as providing the module. The resulting module-to-package
2115 mapping is saved globally in :term:`PKGDATA_DIR` by the
2118 Simultaneously, all pkg-config modules installed by the recipe are
2121 "Requires:" line that specifies the other module. For each module
2123 contains the module. If such a package is found, a runtime dependency
2124 is added from the package that depends on the module to the package
2125 that contains the module.
2129 The
2137 ``bar-dev`` and ``bar-dbg``, respectively. Taking the ``-dev``
2138 packages as an example, the ``bar-dev`` package might provide headers
2139 and shared library symlinks needed by ``foo-dev``, which shows the
2140 need for a dependency between the packages.
2142 The dependencies added by ``depchains`` are in the form of
2148 ``foo``, because the default value of ``RDEPENDS:${PN}-dev`` (set in
2151 To ensure that the dependency chain is never broken, ``-dev`` and
2152 ``-dbg`` packages are always generated by default, even if the
2153 packages turn out to be empty. See the
2157 The ``do_package`` task depends on the ``do_packagedata`` task of each
2160 declaration, which guarantees that the required
2168 operations that are normally reserved for the root user (e.g.
2173 the ``do_install`` task benefits from being able to set the UID and GID
2178 root. However, this method is cumbersome and has security issues. The
2180 privileges in a "fake" root environment. Within this environment, the
2181 task and its child processes believe that they are running as the root
2182 user, and see an internally consistent view of the filesystem. As long
2183 as generating the final output (e.g. a package or an image) does not
2184 require root privileges, the fact that some earlier steps ran in a fake
2187 The capability to run tasks in a fake root environment is known as
2189 the BitBake keyword/variable flag that requests a fake root environment
2192 In the :term:`OpenEmbedded Build System`, the program that implements
2194 overrides system calls by using the environment variable ``LD_PRELOAD``,
2195 which results in the illusion of running as root. To keep track of
2200 for individual recipes. Storing the database in a file as opposed to in
2206 If you add your own task that manipulates the same files or
2208 under fakeroot. Otherwise, the task cannot run root-only operations,
2209 and cannot see the fake file ownership and permissions set by the
2211 ``virtual/fakeroot-native:do_populate_sysroot``, giving the following::
2219 For more information, see the
2220 :term:`FAKEROOT* <bitbake:FAKEROOT>` variables in the
2221 BitBake User Manual. You can also reference the "`Why Not