LTS

    Innovation Version

      Quick Build Guide

      This chapter describes how to build openEuler Embedded.

      Environment Preparation

      Using Host Machine Commands in Yocto

      Yocto, or BitBake, is a group of Python programs. The minimum environment requirements are as follows:

      • Python3 > 3.6.0
      • Git > 1.8.3.1
      • Tar > 1.28

      Yocto can build other tools required in the build process based on the corresponding software package recipes so that Yocto is self-contained. During this process, Yocto installs dedicated Yocto patches for corresponding tools (such as DNF and RPM) as required. These host tools are built from the source code in the first build. Therefore, the first build of Yocto can be time-consuming.

      To accelerate the building process, especially for the first build, openEuler Embedded preferentially uses the pre-built native tools on the host. This requires that the software package management tools (such as APT, DNF, Yum, and Zypper) be installed in advance.

      Yocto uses the HOSTTOOLS variable to introduce host tools and creates a soft link for each tool listed in HOSTTOOLS. To prevent host contamination, Yocto prepares an environment that is independent from the host, for example, the PATH variable. Therefore, if a command that depends on the host is added, the command must be added to HOSTTOOLS. Otherwise, even if the command exists on the host, an error message will be displayed during Yocto building, indicating that the corresponding tool cannot be found. The following figure shows the process.

      The host tools required by openEuler Embedded are defined in HOSTTOOLS in the local.conf.sample file by default. The tools include:

      ToolDescription
      cmakeCMake build tool
      ninjiaNinja build system

      Tools Required for Building openEuler Embedded

      yum -y install tar cmake gperf sqlite-devel chrpath gcc-c++ patch rpm-build flex autoconf automake m4 bison bc libtool gettext-devel createrepo\_c rpcgen texinfo hostname python meson dosfstools mtools parted ninja-build autoconf-archive libmpc-devel gmp-devel
      
      • Pre-built cross-compilation toolchain and library.

        Yocto can build the cross-compilation toolchains and C libraries required for cross-compilation. However, the process is complex and time-consuming and is performed only in the first build. At the same time, most developers do not build toolchains and C libraries themselves. To simplify the process, openEuler Embedded uses pre-built cross-compilation toolchains and libraries maintained by the openEuler community.

        Currently, the toolchains for the ARM32 and AArch64 architectures are provided. You can download the toolchains by performing the following methods:

      Build Container with Tools Installed

      A large number of host tools are used during the build of openEuler Embedded. To accelerate the build process, openEuler Embedded uses the tools installed on the host in advance. However, the tool versions vary depending on the host environment. For example, CMake 1.9 or later is required for the build, but the version on the host is CMake 1.8. To solve this problem, openEuler Embedded provides a dedicated build container to provide a unified build environment.

      You can obtain the container images for the build from the following link:

      Basic Build Container Image for openEuler Embedded

      For details, see the Container Build Guide.

      Version Build

      Downloading Build Code

      The file layout of the openEuler Embedded build project is as follows. Assume that openeuler_embedded is the top-level directory.

      <openeuler_embedded>
      ├── src Source code directory, including all software package code, kernel code, and Yocto build code
      ├── build openEuler Embedded build directory. The generated images are stored in this directory.

      1. Obtain the source code download script.

        Download the script to a specified directory, for example, src/yocto-meta-openeuler.

        git clone https://gitee.com/openeuler/yocto-meta-openeuler.git -b openEuler-22.03-LTS -v src/yocto-meta-openeuler
        

        The script src/yocto-meta-openeuler/scripts/download_code.sh has the following parameters:

          1. Path to download the source code. By default, the source code is downloaded relative to the script location. For example, in the preceding example, the code repository is downloaded to the src/ directory.
          1. Branch to be downloaded. See the script for the default value. Determine the branch based on the version.
          1. XML file for downloading the code, which is in the standard manifest format. The code is downloaded based on the XML configurations.
      2. Download the source code using the script.

        • To download the latest code:

          sh src/yocto-meta-openeuler/scripts/download_code.sh
          
        • To download the code of a specified version:

          sh src/yocto-meta-openeuler/scripts/download_code.sh "" "" "manifest.xml"
          

          Obtain the manifest.xml file for specifying the version of the openEuler Embedded code from the openEuler Embedded release directory embedded_img/source-list/.

      Compiling the Build

      Run the one-click compilation script src/yocto-meta-openeuler/scripts/compile.sh. For details, see the script content.

      The process of the compilation script is as follows:

      1. Adds the paths of the additional tools to PATH.
      2. Sets the TEMPLATECONF variable to include the paths of configuration files such as local.conf.sample.
      3. Invokes oe-init-build-env of the Poky repository to perform initial configuration.
      4. Sets the MACHINE variable in the conf/local.conf file in the compilation directory to add layers as required.
      5. Runs the bitbake openeuler-image command in the compilation directory to build the image and SDK of openEuler Embedded.
      6. The files are generated in the output directory of the compilation directory.

      Run the compilation script. The following uses the standard ARM architecture as an example to describe the compilation method:

      source src/yocto-meta-openeuler/scripts/compile.sh arm-std
      bitbake openeuler-image # You will be prompted to run the bitbake command after the source command is executed
      

      Build Result

      By default, the files are generated in the output directory of the build directory. For example, the built files of the ARM example are generated in the /usr1/build/output directory, as shown in the following table:

      filenamedescription
      Image-*openEuler Embedded image
      openeuler-glibc-x86_64-openeuler-image-*-toolchain-**.shopenEuler Embedded sdk toolchain
      openeuler-image-qemu-aarch64-*.rootfs.cpio.gzopenEuler Embedded file system
      zImageopenEuler Embedded compressed image

      Bug Catching

      Buggy Content

      Bug Description

      Submit As Issue

      It's a little complicated....

      I'd like to ask someone.

      PR

      Just a small problem.

      I can fix it online!

      Bug Type
      Specifications and Common Mistakes

      ● Misspellings or punctuation mistakes;

      ● Incorrect links, empty cells, or wrong formats;

      ● Chinese characters in English context;

      ● Minor inconsistencies between the UI and descriptions;

      ● Low writing fluency that does not affect understanding;

      ● Incorrect version numbers, including software package names and version numbers on the UI.

      Usability

      ● Incorrect or missing key steps;

      ● Missing prerequisites or precautions;

      ● Ambiguous figures, tables, or texts;

      ● Unclear logic, such as missing classifications, items, and steps.

      Correctness

      ● Technical principles, function descriptions, or specifications inconsistent with those of the software;

      ● Incorrect schematic or architecture diagrams;

      ● Incorrect commands or command parameters;

      ● Incorrect code;

      ● Commands inconsistent with the functions;

      ● Wrong screenshots.

      Risk Warnings

      ● Lack of risk warnings for operations that may damage the system or important data.

      Content Compliance

      ● Contents that may violate applicable laws and regulations or geo-cultural context-sensitive words and expressions;

      ● Copyright infringement.

      How satisfied are you with this document

      Not satisfied at all
      Very satisfied
      Submit
      Click to create an issue. An issue template will be automatically generated based on your feedback.
      Bug Catching
      编组 3备份