Yocto编译杰发或MTK的linux或android时的几个问题

编译问题1（audiomanager_7.0.bb的do_configure报错）：

错误：CMake Error at Plugins/PluginCommandInterfaceCAPI/cmake/CommonAPI.cmake:352 (message):

|   Failed to generate files from FIDL:

手动执行一下：

$ commonapi-generator-linux-x86 -ll verbose -sk Default -d . /data/linux/hz_rs28_bm/sources/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/audiomanager/7.0-r1/audiomanager-7.0/Plugins/PluginCommandInterfaceCAPI/fidl/CommandInterface.fidl

-bash: /data/linux/hz_rs28_bm/sources/src/build/tools/commonapi_tool/commonapi-generator/commonapi-generator-linux-x86: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory

解决（需要安装32位的glibc库和32位java jre环境）：

$ sudo yum install glibc.i686

$ sudo yum install java-1.8.0-openjdk.i686

$ sudo ln -s /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.191.b12-1.el7_6.i386/jre/bin/java /bin/java

$ java -version    （保证是32位的java）

编译问题2（perl_5.20.0.bb的do_package报错）：

错误：ERROR: objcopy failed with exit code 256 (cmd was ‘arm-poky-linux-gnueabi-objcopy’ –only-keep-debug

… generate_uudmap: File format not recognized

解决（tar在1.29版本之后需要exclude在路径的前面）：

sources/meta/poky/bitbake/lib/bb/fetch2/bzr.py

tar_flags = “–exclude ‘.bzr’ –exclude ‘.bzrtags'”

修改成：

tar_flags = “–exclude=’.bzr’ –exclude=’.bzrtags'”

sources/meta/poky/bitbake/lib/bb/fetch2/cvs.py

tar_flags = “–exclude ‘CVS'”

修改成：

tar_flags = “–exclude=’CVS'”

sources/meta/poky/bitbake/lib/bb/fetch2/repo.py

tar_flags = “–exclude ‘.repo’ –exclude ‘.git'”

修改成：

tar_flags = “–exclude=’.repo’ –exclude=’.git'”

sources/meta/poky/bitbake/lib/bb/fetch2/svn.py

tar_flags = “–exclude ‘.svn'”

修改成：

tar_flags = “–exclude=’.svn'”

sources/meta/poky/meta/recipes-devtools/quilt/quilt-0.63.inc

       tar -cf – bin/ –exclude \*.in | ( cd ${D}${PTEST_PATH} &&tar -xf – )

       tar -cf – compat/ –exclude \*.in | ( cd ${D}${PTEST_PATH} &&tar -xf – )

       tar -cf – quilt/ –exclude \*.in | ( cd ${D}${PTEST_PATH} &&tar -xf – )

       tar -cf – test/ –exclude mail.test –exclude delete.test | ( cd ${D}${PTEST_PATH} &&tar -xf – )

修改成：

        tar -c –exclude=\*.in bin/ | ( cd ${D}${PTEST_PATH} &&tar -xf – )

        tar -c –exclude=\*.in compat/ | ( cd ${D}${PTEST_PATH} &&tar -xf – )

        tar -c –exclude=\*.in quilt/ | ( cd ${D}${PTEST_PATH} &&tar -xf – )

        tar -c –exclude=mail.test –exclude=delete.test test/ | ( cd ${D}${PTEST_PATH} &&tar -xf – &&chmod 777 test)

sources/meta/poky/meta/recipes-extended/sed/sed-4.2.2/sed-add-ptest.patch

+       cd $(BUILDDIR)tar -cf – $(TESTDIR) –exclude *.o | ( cd $(DESTDIR) &&tar -xf – )

修改成：

+       cd $(BUILDDIR)tar -c –exclude=*.o $(TESTDIR) | ( cd $(DESTDIR) &&tar -xf – )

sources/meta/poky/meta/recipes-support/attr/acl.inc

tar -cf – test/ –exclude nfs | ( cd ${D}${PTEST_PATH} &&tar -xf – )

修改成：

tar -c –exclude=nfs test/ | ( cd ${D}${PTEST_PATH} &&tar -xf – )

sources/meta/poky/meta/recipes-support/attr/attr.inc

tar -cf – test/ –exclude ext | ( cd ${D}${PTEST_PATH} &&tar -xf – )

修改成：

tar -c –exclude=ext test/ | ( cd ${D}${PTEST_PATH} &&tar -xf – )

sources/meta/poky/meta/recipes-devtools/perl/perl-ptest.inc

       tar -cf – * –exclude \*.o –exclude libperl.so –exclude Makefile –exclude makefile –exclude hostperl \

               –exclude miniperl –exclude generate_uudmap –exclude patches | ( cd ${D}${PTEST_PATH} &&tar -xf – )

修改成：

        tar -c –exclude=\*.o –exclude=libperl.so –exclude=Makefile –exclude=makefile –exclude=hostperl \

                –exclude=miniperl –exclude=generate_uudmap –exclude=patches * | ( cd ${D}${PTEST_PATH} &&tar -x )

编译问题3（libunwind_1.1.bb的do_compile报错）：

错误：make[1]: latex2man: Command not found

解决：

$ sudo yum install texlive-tetex

$ sudo rpm -ivh ~/latex2man-1.18-2.noarch.rpm

编译问题3（qt5-app_1.0.bb的do_compile报错）：

错误（有一批类似的错误）：ld: cannot find -lgtest

解决：

$ vi atc_linux/application/btate/btate.pro

equals(MY_BUILD_SYSTEM, atc) {

    LIBS += -L $(DA_LIBDIR)/lib -lgtest -lpthread -lbluetoothclient -lglobalbus -lappobj -lapputils

} else {

    LIBS += -L$(DA_TOP)/application/lib -L$(DA_TOP)/../../sources/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/atc-binarys/1.0-r0/image/usr/lib -lgtest -lpthread -lbluetoothclient -l

globalbus -lappobj -lapputils

}

$ vi atc_linux/application/gps/gps_bin.pro

equals(MY_BUILD_SYSTEM, atc) {

    LIBS += -L $(DA_LIBDIR)/lib  -lapputils  -lglobalbus -lappobj -lgps

} else {

    LIBS += -L$(DA_TOP)/application/lib -L$(DA_TOP)/../../sources/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/gpsd/3.10-r0/gpsd-3.10/ -lapputils  -lglobalbus -lappobj -lgps

}

$ vi atc_linux/application/dvr/dvr_bin.pro

equals(MY_BUILD_SYSTEM, atc) {

        LIBS    += -L${DA_TOP}/lib/lib/ -ldvr -ludev -lsurface_atc -lglobalbus -lappobj -lapputils -lstorage_atc -lgps

} else {

        LIBS    += -L${DA_TOP}/application/lib -L$(DA_TOP)/../../sources/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/gpsd/3.10-r0/gpsd-3.10/ -ldvr -ludev -lsurface_atc -lglobalbus –

lappobj -lapputils -lstorage_atc -lgps

}

$ vi atc_linux/application/dvr/dvr_bin.pro

INCLUDEPATH +=  ${DA_TOP}/kernel/kernel-3.18/drivers/ \

                ../common/  \

                ../utils/   \

                ../appobj/include/          \

                ../globalbus/include/       \

                ../appcommon/include/       \

                ../storage_atc/             \

                ../dvr/gps/             \

                ../gps/include/         \

                ../gps/includeex/       \

编译问题4（makall报错）：

报错：./makall: line 169: mkisofs: command not found

解决：$ sudo yum install mkisofs

编译问题5（修改ac83xx_systemd_defconfig再编译时报错）：

报错：Applying patch remove-selinux-android.patch

patching file system/extras/ext4_utils/make_ext4fs.c

Hunk #1 FAILED at 62.

1 out of 1 hunk FAILED — rejects in file system/extras/ext4_utils/make_ext4fs.c

解决：

$ vi sources/meta/meta-atc/recipes-devtools/android-tools/android-tools_5.1.1.r37.bb

在里面做个假的do_patch()，bitbake会优先使用本bb文件的do_patch()函数。

do_patch(){

}

编译问题6（修改ac83xx_systemd_defconfig再编译时报错）：

报错：sources/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/qtbase/5.5.0+gitAUTOINC+c619d2daac-r0/git/src/corelib/tools/qregexp.cpp:3947:1: internal compiler error: in add_stores, at var-tracking.c:6000

解决：

$ cd sources/meta/poky/meta/recipes-devtools/gcc/gcc-4.9/

$ wget  http://openlinux.windriver.com/overc/sources/core2_64/gcc-4.9.2-r0.1/0062-gcc-var-tracking.c-backport-from-gcc-trunk-r212178.patch

$ vi sources/meta/poky/meta/recipes-devtools/gcc/gcc-4.9.inc

    file://0058-gcc-r212171.patch \

    file://0059-gcc-PR-rtl-optimization-63348.patch \

    file://target-gcc-includedir.patch \

    file://0062-gcc-var-tracking.c-backport-from-gcc-trunk-r212178.patch \

其实就是这个文件：

$ cat 0062-gcc-var-tracking.c-backport-from-gcc-trunk-r212178.patch

From b30ffb8097749fdb55704aa7d8307ca1a58255d6 Mon Sep 17 00:00:00 2001

From: =?UTF-8?q?Stefan=20M=C3=BCller-Klieser?= <s.mueller-klieser@phytec.de>

Date: Tue, 7 Apr 2015 16:15:11 +0200

Subject: [PATCH] gcc/var-tracking.c: backport from gcc trunk r212178

MIME-Version: 1.0

Content-Type: text/plaincharset=UTF-8

Content-Transfer-Encoding: 8bit

resolves a bug seen on cortexa8 building qt5 libraries.

2014-06-30  Joseph Myers  <joseph@codesourcery.com>

    * var-tracking.c (add_stores): Return instead of asserting if old

    and new values for conditional store are the same.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@212178 138bc75d-0d04-0410-961f-82ee72b054a4

Signed-off-by: Stefan Müller-Klieser <s.mueller-klieser@phytec.de>

---

gcc/var-tracking.c | 3 ++-

1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/var-tracking.c b/gcc/var-tracking.c

index 65d8285..7c38910 100644

--- a/gcc/var-tracking.c

+++ b/gcc/var-tracking.c

@@ -5997,7 +5997,8 @@ add_stores (rtx loc, const_rtx expr, void *cuip)

    {

      cselib_val *oval = cselib_lookup (oloc, GET_MODE (oloc), 0, VOIDmode)

-      gcc_assert (oval != v)

+      if (oval == v)

+        return

      gcc_assert (REG_P (oloc) || MEM_P (oloc))

      if (oval &&!cselib_preserved_value_p (oval))

--

1.9.1

编译问题7（修改ac83xx_systemd_defconfig再编译时报错）：

报错：libevdev/1.2.2-r0/libevdev-1.2.2/test/test-main.c:24:19: fatal error: check.h: No such file or directory

解决：

$ vi meta/poky/meta/recipes-support/libevdev/libevdev_1.2.2.bb

LIC_FILES_CHKSUM = “file://COPYINGmd5=75aae0d38feea6fda97ca381cb9132eb \

                    file://libevdev/libevdev.hendline=21md5=7ff4f0b5113252c2f1a828e0bbad98d1″

DEPENDS += “libcheck”

SRC_URI = “ http://www.freedesktop.org/software/libevdev/ ${BP}.tar.xz”

编译问题8（修改ac83xx_systemd_defconfig再编译时报错）：

报错：python报错： ‘do_rootfs’, lineno: 17, function

Exception: CalledProcessError: Command ‘[‘du’, ‘-ks’, …

解决： 没有实际问题，重新编译一次即可，可能是机器太忙导致超时，或者某个命令执行不成功。

编译问题9（preuboot编译工具问题）：

报错：make: armv7a-mediatek451_001_vfp-linux-gnueabi-gcc: Command not found

解决：

$ vi atc_linux/bootloader/preuboot/Makefile

#CROSS_COMPILE  :=armv7a-mediatek451_001_vfp-linux-gnueabi-

CROSS_COMPILE  :=arm-poky-linux-gnueabi-

$ vi ../../atc_linux/bootloader/preuboot/driver/mmc/include/linux/list.h

#ifndef NULL

    #define NULL 0

#endif

项目越来越大，每次需要重新编译整个项目都是一件很浪费时间的事情。Research了一下，找到以下可以帮助提高速度的方法，总结一下。

1. 使用tmpfs来代替部分IO读写

2.ccache，可以将ccache的缓存文件设置在tmpfs上，但是这样的话，每次开机后，ccache的缓存文件会丢失

3.distcc,多机器编译

4.将屏幕输出打印到内存文件或者/dev/null中，避免终端设备（慢速设备）拖慢速度。

　tmpfs

有人说在Windows下用了RAMDisk把一个项目编译时间从4.5小时减少到了5分钟，也许这个数字是有点夸张了，不过粗想想，把文件放到内存上做编译应该是比在磁盘上快多了吧，尤其如果编译器需要生成很多临时文件的话。

这个做法的实现成本最低，在Linux中，直接mount一个tmpfs就可以了。而且对所编译的工程没有任何要求，也不用改动编译环境。

mount -t tmpfs tmpfs ~/build -o size=1G

用2.6.32.2的Linux Kernel来测试一下编译速度：

用物理磁盘：40分16秒

用tmpfs：39分56秒

呃……没什么变化。看来编译慢很大程度上瓶颈并不在IO上面。但对于一个实际项目来说，编译过程中可能还会有打包等IO密集的 *** 作，所以只要可能，用tmpfs是有益无害的。当然对于大项目来说，你需要有足够的内存才能负担得起这个tmpfs的开销。

make -j

既然IO不是瓶颈，那CPU就应该是一个影响编译速度的重要因素了。

用make -j带一个参数，可以把项目在进行并行编译，比如在一台双核的机器上，完全可以用make -j4，让make最多允许4个编译命令同时执行，这样可以更有效的利用CPU资源。

还是用Kernel来测试：

用make： 40分16秒

用make -j4：23分16秒

用make -j8：22分59秒

由此看来，在多核CPU上，适当的进行并行编译还是可以明显提高编译速度的。但并行的任务不宜太多，一般是以CPU的核心数目的两倍为宜。

不过这个方案不是完全没有cost的，如果项目的Makefile不规范，没有正确的设置好依赖关系，并行编译的结果就是编译不能正常进行。如果依赖关系设置过于保守，则可能本身编译的可并行度就下降了，也不能取得最佳的效果。

ccache

ccache工作原理：

ccache也是一个编译器驱动器。第一趟编译时ccache缓存了GCC的“-E”输出、编译选项以及.o文件到$HOME/.ccache。第二次编译时尽量利用缓存，必要时更新缓存。所以即使"make cleanmake"也能从中获得好处。ccache是经过仔细编写的，确保了与直接使用GCC获得完全相同的输出。

ccache用于把编译的中间结果进行缓存，以便在再次编译的时候可以节省时间。这对于玩Kernel来说实在是再好不过了，因为经常需要修改一些Kernel的代码，然后再重新编译，而这两次编译大部分东西可能都没有发生变化。对于平时开发项目来说，也是一样。为什么不是直接用make所支持的增量编译呢？还是因为现实中，因为Makefile的不规范，很可能这种“聪明”的方案根本不能正常工作，只有每次make clean再make才行。

安装完ccache后，可以在/usr/local/bin下建立gcc，g++，c++，cc的symbolic link，链到/usr/bin/ccache上。总之确认系统在调用gcc等命令时会调用到ccache就可以了（通常情况下/usr/local /bin会在PATH中排在/usr/bin前面）。

安装的另外一种方法：

vi ~/.bash_profile

把/usr/lib/ccache/bin路径加到PATH下

PATH=/usr/lib/ccache/bin:$PATH:$HOME/bin

这样每次启动g++的时候都会启动/usr/lib/ccache/bin/g++，而不会启动/usr/bin/g++

效果跟使用命令行ccache g++效果一样

这样每次用户登录时，使用g++编译器时会自动启动ccache

继续测试：

用ccache的第一次编译(make -j4)：23分38秒

用ccache的第二次编译(make -j4)：8分48秒

用ccache的第三次编译(修改若干配置，make -j4)：23分48秒

看来修改配置（我改了CPU类型...）对ccache的影响是很大的，因为基本头文件发生变化后，就导致所有缓存数据都无效了，必须重头来做。但如果只是修改一些.c文件的代码，ccache的效果还是相当明显的。而且使用ccache对项目没有特别的依赖，布署成本很低，这在日常工作中很实用。

可以用ccache -s来查看cache的使用和命中情况：

cache directory /home/lifanxi/.ccachecache hit　 7165cache miss 14283called for link　 71not a C/C++ file　 　 120no input file　 3045files in cache 28566cache size 81.7 Mbytesmax cache size 976.6 Mbytes

可以看到，显然只有第二编次译时cache命中了，cache miss是第一次和第三次编译带来的。两次cache占用了81.7M的磁盘，还是完全可以接受的。

distcc

一台机器的能力有限，可以联合多台电脑一起来编译。这在公司的日常开发中也是可行的，因为可能每个开发人员都有自己的开发编译环境，它们的编译器版本一般是一致的，公司的网络也通常具有较好的性能。这时就是distcc大显身手的时候了。

使用distcc，并不像想象中那样要求每台电脑都具有完全一致的环境，它只要求源代码可以用make -j并行编译，并且参与分布式编译的电脑系统中具有相同的编译器。因为它的原理只是把预处理好的源文件分发到多台计算机上，预处理、编译后的目标文件的链接和其它除编译以外的工作仍然是在发起编译的主控电脑上完成，所以只要求发起编译的那台机器具备一套完整的编译环境就可以了。

distcc安装后，可以启动一下它的服务：

/usr/bin/distccd --daemon --allow 10.64.0.0/16

默认的3632端口允许来自同一个网络的distcc连接。

然后设置一下DISTCC_HOSTS环境变量，设置可以参与编译的机器列表。通常localhost也参与编译，但如果可以参与编译的机器很多，则可以把localhost从这个列表中去掉，这样本机就完全只是进行预处理、分发和链接了，编译都在别的机器上完成。因为机器很多时，localhost的处理负担很重，所以它就不再“兼职”编译了。

export DISTCC_HOSTS="localhost 10.64.25.1 10.64.25.2 10.64.25.3"

然后与ccache类似把g++，gcc等常用的命令链接到/usr/bin/distcc上就可以了。

在make的时候，也必须用-j参数，一般是参数可以用所有参用编译的计算机CPU内核总数的两倍做为并行的任务数。

同样测试一下：

一台双核计算机，make -j4：23分16秒

两台双核计算机，make -j4：16分40秒

两台双核计算机，make -j8：15分49秒

跟最开始用一台双核时的23分钟相比，还是快了不少的。如果有更多的计算机加入，也可以得到更好的效果。

在编译过程中可以用distccmon-text来查看编译任务的分配情况。distcc也可以与ccache同时使用，通过设置一个环境变量就可以做到，非常方便。

总结一下：

tmpfs： 解决IO瓶颈，充分利用本机内存资源

make -j： 充分利用本机计算资源

distcc： 利用多台计算机资源

ccache： 减少重复编译相同代码的时间

这些工具的好处都在于布署的成本相对较低，综合利用这些工具，就可以轻轻松松的节省相当可观的时间。上面介绍的都是这些工具最基本的用法，更多的用法可以参考它们各自的man page。

5.还有提速方法是把屏幕输出重定向到内存文件或/dev/null,因对终端设备(慢速设备)的阻塞写 *** 作也会拖慢速度。推荐内存文件，这样发生错误时，能够查看。

android虽然是基于linux的，但是他们并不是二进制兼容的。

android的工作方式是，在linux系统中运行一个基于qemu的虚拟机，在虚拟机中运行java虚拟机。android程序的api还是以java为主的，所以android是不支持J2sejava程序的。

所以一个随便的linux程序代码是不可以编译成android软件的。

如果你想在android手机上运行python perl 或者shall脚本的话，是可以的，在android上有专门的终端什么的。

---