使用Buildroot编译第三方工具

1. 概述

本sdk的第三方开源工具统一使用Buildroot进行维护管理及构建，本文档简单描述Buildroot的使用及可能出现的问题处理。

2. 基本使用

  • 设置编译工具链

    使用export将编译工具链的路径添加到PATH环境变量中，与平常使用无异不再赘述。这里使用gcc 10.2.1 aarch64版本进行描述。

  • make defconfig

    当前根据实际需要用到的软件列表添加了一个新的defconfig，类似kernel的构建，先使用make sstar_gcc_10_2_1_aarch64_defconfig生成正确的“.config”文件

  • 使用make source提前单独下载所需源码（可忽略）

    因Buildroot本身只是一堆编译的脚本，编译时会自动从指定的位置下载源码及patch进行构建。为避免因网络等问题可能出现下载较慢或出错影响构建的速度，我们可以使用make source提交单独下载所需的源码，必要时可通过本地pc机下载然后放到适当的位置。如：make source时发现procps-ng-3.3.15.tar.xz包下载太慢，我们可以从输出的log中找到这个包的下载路径，之后通过pc端手动下载并放到dl/procps-ng/目录。

  • make开始构建

    直接make构建已选择的所有包，也可以使用make xxx单独编译某个包，如make procps-ng

  • 添加一个自己的package

    可参考package/vendor_storage/（本地源码方式）修改中添加vendor_storage的方式，也可参考其他现有的包通过网络下载源码的方式处理，使用方法与kernel的Kconfig基本一致。

    pic

  • 通过patch添加开源代码的客制化修改

    参考package/procps-ng/0001-Fix_garbled_code_issue_when_using_top_cmd_via_adb.patch添加procps-ng的本地修改patch，基本使用方法是修改一份文件后通过diff -u命令与原生文件对比生成patch并放到package中相应的目录下，构建时将会按照序号使用patch命令对源码进行patch。

    pic

3. 构建问题处理

  • toolchain & kernel header问题

    需要更换默认的toolchain时可能会发现toolchain使用的kernel header版本与defconfig中指定的不匹配问题，在编译过程中出现类似如下的log，defconfig指定使用5.10的版本，而实际我们的toolchain是依赖4.19版本的kernel header构建的

    pic

    通过make menuconfig或直接编辑defconfig将kernel版本修改为指定的版本即可，如下

    pic

  • LD_LIBRARY_PATH问题

    设置了LD_LIBRARY_PATH环境变量的话编译使会报以下错误，通过unset去除环境变量设置即可

    pic

  • iconv相关问题

    编译服务器若是安装了libiconv，在编译libglib库是会出现libiconv_open等相关报错，这是因为搜索头文件时优先搜索的是libiconv的头文件，会通过宏定义强制将iconv_open转为libiconv_open。而实际链接时使用的又是GNU iconv（没有libiconv_open等接口）导致链接失败。错误信息如下：

    pic

    处理方式可以选择卸载掉libiconv或设置C_INCLUDE_PATH环境变量修改默认的头文件搜索顺序（当前Buildroot构建不可行，会导致c++的boost编译异常）等方式处理，但我们没有编译服务器的root权限无法处理。目前修改的方法是找到出错的文件，在最开头的位置添加LIBICONV_PLUG宏定义以强制使用原始的iconv_open接口，如下：

    pic