Buildroot Compilation User Guide

1. Overview

The third-party open source tools of this SDK are uniformly maintained, managed and built using Buildroot. This document briefly describes the use of Buildroot and the handling of possible problems.

2. Basic usage

  • Set up the compilation toolchain

    Use export to add the path of the compilation toolchain to the PATH environment variable. This is the same as normal use and will not be described in detail. Here we use gcc 10.2.1 aarch64 version for description.

  • make defconfig

    Currently, a new defconfig is added according to the software list actually needed. Similar to the kernel build, first use make sstar_gcc_10_2_1_aarch64_defconfig to generate the correct ".config" file

  • Use make source to download the required source code separately in advance (can be ignored)

    Because Buildroot itself is just a bunch of compiled scripts, it will automatically download the source code and patch from the specified location for building during compilation. To avoid slow downloads or errors due to network problems that may affect the speed of building, we can use make source to submit the required source code for separate downloads. If necessary, we can download it from the local PC and put it in the appropriate location. For example, when making source, we find that the procps-ng-3.3.15.tar.xz package is too slow to download. We can find the download path of this package from the output log, and then manually download it from the PC and put it in the dl/procps-ng/ directory.

  • make starts the build

    Directly use make to build all selected packages. You can also use make xxx to compile a package separately, such as make procps-ng

  • Add a package of your own

    You can refer to the method of modifying and adding vendor_storage in package/vendor_storage/ (local source code method), or refer to other existing packages to download source code through the network. The usage method is basically the same as kernel Kconfig.

  • Add customized modifications to open source code through patches

    Refer to package/procps-ng/0001-Fix_garbled_code_issue_when_using_top_cmd_via_adb.patch to add the local modification patch of procps-ng. The basic usage method is to modify a file and compare it with the original file through the command diff -u to generate a patch and put it in the corresponding directory in the package. When building, the patch command will be used to patch the source code according to the sequence number.

3. Build problem handling

  • toolchain & kernel header issues

    When you need to replace the default toolchain, you may find that the kernel header version used by the toolchain does not match the version specified in defconfig. During the compilation process, a log similar to the following appears. defconfig specifies the use of version 5.10, but our toolchain is actually built based on version 4.19 of the kernel header.

    Use make menuconfig or directly edit defconfig to change the kernel version to the specified version, as follows

  • LD_LIBRARY_PATH issue

    If the LD_LIBRARY_PATH environment variable is set, the compiler will report the following error. You can remove the environment variable setting by unset

  • iconv related issues

    If libiconv is installed on the compilation server, errors related to libiconv_open will appear when compiling the libglib library. This is because the header file of libiconv is searched first when searching for header files, and iconv_open will be forced to be converted to libiconv_open through macro definition. However, GNU iconv (which does not have libiconv_open and other interfaces) is used during actual linking, which causes linking failure. The error message is as follows:

    The solution is to uninstall libiconv or set the C_INCLUDE_PATH environment variable to modify the default header file search order (this is not feasible for the current Buildroot build, which will cause abnormal compilation of C++ boost). However, we do not have the root privilege of the compilation server and cannot handle this. The current modification method is to find the error file and add the LIBICONV_PLUG macro definition at the very beginning to force the use of the original iconv_open interface, as follows: