一文搞懂,Linux交叉编译(x86~ARM)

一文搞懂 x86 与 ARM 交叉编译：为什么程序在 Ubuntu 能跑，放到开发板却跑不起来？

做嵌入式开发时，很多人都会遇到这样一个经典问题：

在 Ubuntu 上辛辛苦苦把程序编出来了，make 没报错，adb push 也成功了，结果一放到 ARM 开发板上运行，却直接报错：

cannot execute binary file

或者：

No such file or directory

明明文件都拷过去了，为什么还是跑不起来？

问题的根源，往往只有四个字：

架构不匹配。

今天这篇文章，我们就用最通俗的方式，把 x86、ARM、交叉编译、Qt 工具链、开发板部署 这一整套逻辑讲明白。

一、什么是 x86？什么是 ARM？

1. x86 是什么？

x86 通常指的是 PC 电脑常见的处理器架构，比如：

• Intel
• AMD

你的 Ubuntu 开发机，大概率就是：

• x86_64
• 也叫 64 位 x86

在 Ubuntu 里执行：

uname -m

常见输出就是：

x86_64

这说明你当前电脑的 CPU 架构是 x86_64。

2. ARM 是什么？

ARM 是另一类处理器架构，广泛用于：

• 开发板
• 路由器
• 工控设备
• 智能硬件
• 手机
• 嵌入式 Linux 设备

比如很多全志、瑞芯微、NXP、海思平台，跑的都是 ARM。

在 ARM 板子上执行：

uname -m

常见输出可能是：

armv7l

或者：

aarch64

含义分别是：

• armv7l：32 位 ARM
• aarch64：64 位 ARM

二、为什么在 Ubuntu 上编出来的程序，开发板不能运行？

假设你在 Ubuntu 上直接执行：

qmake myApp.promake

最后再看一下生成文件：

file myApp

输出可能是：

ELF 64-bit LSB executable, x86-64

这说明这个程序是：

• 在 Ubuntu 上编译的
• 目标架构也是 Ubuntu 主机架构
• 也就是 x86_64 程序

如果你把这个程序拷到 ARM 板子上运行，板子当然认不出来，因为它需要的是：

• ARM 程序
• 不是 x86 程序

这就像：

• 把 Windows 程序拷到安卓手机里
• 文件是能复制过去
• 但系统根本不能执行

所以这里要记住一句非常关键的话：

编译机在哪，不重要；重要的是你编译出来的目标程序是给谁跑的。

三、什么叫交叉编译？

所谓交叉编译，其实一句话就能说明白：

在一种平台上，编译出能在另一种平台上运行的程序。

举个最常见的例子：

• 你在 Ubuntu x86_64 电脑上开发
• 但程序最终要跑在 ARM 开发板上

那么你就需要：

• 在 x86 主机上
• 使用 ARM 工具链
• 编译出 ARM 可执行文件

这件事就叫：

交叉编译

四、本地编译和交叉编译有什么区别？

我们可以把它们对比着看。

1. 本地编译

本地编译是指：

• 在什么机器上编译
• 就给什么机器运行

比如：

• Ubuntu x86_64 上编译
• 生成 x86_64 程序
• 再在 Ubuntu x86_64 上运行

这就是本地编译。

2. 交叉编译

交叉编译是指：

• 在 A 平台上编译
• 生成给 B 平台运行的程序

比如：

• Ubuntu x86_64 上编译
• 生成 ARMv7 程序
• 放到 ARM 开发板运行

这就是交叉编译。

五、怎么判断自己到底编成了 x86 还是 ARM？

这个命令非常重要：

file 程序名

例如：

file myRecoder

如果输出里有：

x86-64

说明它是 PC 版程序。

如果输出里有：

ARM

或者：

aarch64

说明它是 ARM 程序。

最典型的几种情况如下。

情况 1：x86_64 主机程序

ELF 64-bit LSB executable, x86-64

情况 2：32 位 ARM 程序

ELF 32-bit LSB executable, ARM, EABI5

情况 3：64 位 ARM 程序

ELF 64-bit LSB executable, ARM aarch64

很多时候，问题根本不用猜，file 一看就清楚了。

六、为什么很多人会“误编译”成 x86 版本？

因为默认使用了系统自带编译工具。

比如在 Ubuntu 里执行：

which qmakeqmake -v

如果输出是：

/usr/bin/qmakeUsing Qt version 5.x in /usr/lib/x86_64-linux-gnu

那基本可以确定：

你用的是 Ubuntu 主机的 Qt，不是 ARM 工具链。

这意味着你执行：

qmakemake

编出来的程序自然也是：

x86_64 版本

而不是 ARM 版本。

七、Qt 项目里，交叉编译最容易错在哪？

在 Qt 开发中，最常见的坑就是：

1. 用错 qmake

Qt 的交叉编译，核心不只是 make，而是：

你用的是哪个 qmake。

因为不同的 qmake，背后绑定的是不同的：

• mkspec
• 编译器
• sysroot
• Qt 库路径
• 头文件路径

比如下面这个：

/usr/bin/qmake

一般是主机版。

而下面这种：

/home/zhiwan/t113/QT/staging_dir/qt-everywhere-src-5.12.9/arm-qt/bin/qmake

才更像是 ARM 目标环境的 qmake。

所以一句话概括：

Qt 交叉编译，本质上先选对 qmake，再谈 make。

八、x86 到 ARM 的标准交叉编译流程

下面给一套最实用的通用流程。

第一步：确认主机架构

在 Ubuntu 上执行：

uname -m

一般会看到：

x86_64

第二步：确认目标板架构

在开发板上执行：

uname -m

例如输出：

armv7l

这说明目标板是：

• 32 位 ARM

第三步：找到 ARM 交叉工具链

如果是 Qt 项目，重点找的是：

qmake

比如：

find /home -name qmake 2>/dev/nullfind /opt -name qmake 2>/dev/null

然后挑出明显和 ARM 相关的版本，比如：

.../arm-qt/bin/qmake.../usr/lib/arm-qt/bin/qmake

不要误用：

/usr/bin/qmake/opt/Qt/.../gcc_64/bin/qmake

第四步：清理旧的 x86 编译产物

如果你之前已经在源码目录编过一次 x86 版本，必须先清理。

make cleanrm -f .qmake.stash

如果不干净，也可以手工删：

rm -f Makefilerm -f 程序名rm -f *.orm -f moc_*.cpprm -f moc_*.orm -f ui_*.hrm -f .qmake.stash

这一步非常重要。 因为旧的 Makefile、旧的中间文件，很容易导致你“看起来换了工具链，实际上还在复用旧结果”。

第五步：用 ARM 版 qmake 重新生成 Makefile

例如：

/path/to/arm-qmake myRecoder.pro

然后执行：

make -j4

第六步：检查输出文件架构

编译完不要急着推板子，先看：

file myApp

如果输出是：

ELF 32-bit LSB executable, ARM

那说明方向正确。

如果还是：

x86-64

那就说明你工具链还是用错了。

第七步：部署到开发板

例如：

adb push myApp /root/adb shellcd /rootchmod +x myApp./myApp

如果程序能正常启动，说明交叉编译阶段基本成功。

九、为什么 adb push 成功了，程序还是不能运行？

这是另一个很典型的误区。

adb push 只是：

文件传输成功

它不代表：

• 文件架构正确
• 库依赖满足
• 程序一定能执行

所以很多人看到：

1 file pushed

就以为万事大吉，结果一运行还是报错。

本质上，adb push 只管拷贝，不管兼容性。

十、程序架构对了，为什么还可能运行失败？

即使你已经把程序编成 ARM，也不代表百分百能跑。

还可能遇到下面几类问题。

1. 缺少动态库

最常见报错是：

error while loading shared libraries: libQt5Core.so.5: cannot open shared object file

这说明程序是 ARM 的，但板子上没有相应 Qt 动态库。

2. 平台插件缺失

Qt 程序经常会遇到：

• xcb 插件问题
• linuxfb 插件问题
• eglfs 插件问题

嵌入式 Linux 常见场景下，需要根据显示环境设置：

export QT_QPA_PLATFORM=linuxfb

或者使用其他适合板子的 Qt 平台插件。

3. 运行环境变量不完整

比如：

QStandardPaths: XDG_RUNTIME_DIR not set

这个通常问题不大，但说明环境不完整。

4. 音频、摄像头、串口等外设问题

如果你的程序涉及：

• 录音
• 播放
• 摄像头
• 串口
• 触摸屏

那么即使程序本身能启动，也可能因为设备节点、驱动、权限等原因出问题。

十一、结合实际项目，怎样快速判断问题出在哪？

这里给一个非常实用的排查思路。

第一步：看程序是不是 ARM

file 程序名

第二步：看板子是不是 ARMv7 还是 aarch64

uname -m

第三步：确认 qmake 是不是 ARM 版本

which qmakeqmake -v

或者直接执行你怀疑的 ARM qmake：

/path/to/arm-qmake -v

第四步：确认运行时报的是架构错，还是缺库

如果是：

cannot execute binary file

那一般是架构不对。

如果是：

No such file or directory

在嵌入式环境里不一定真是“文件不存在”，也可能是：

• 动态加载器不存在
• 依赖库缺失
• 解释器路径不对

如果是：

error while loading shared libraries

那就是依赖库问题。

十二、经验

很多人一看到程序上板失败，第一反应是：

• 是不是源码有 bug？
• 是不是 Qt 控件有问题？
• 是不是线程写错了？

其实很多时候，代码根本没问题，问题只是出在：

• 编译架构不对
• 工具链选错
• 库没带齐
• 运行环境不完整

所以做嵌入式交叉编译，最重要的不是一上来改代码，而是先把这几个基础问题确认清楚：

1. 主机是什么架构
2. 目标板是什么架构
3. 当前工具链编出来的是谁的程序
4. 程序依赖的库在不在目标板上

十三、常用命令

查看主机/目标板架构

uname -muname -a

查看程序架构

file 程序名

查看当前 qmake

which qmakeqmake -v

查找系统里的 qmake

find /home -name qmake 2>/dev/nullfind /opt -name qmake 2>/dev/nullfind /usr/local -name qmake 2>/dev/null

清理旧构建

make cleanrm -f .qmake.stash

用指定 qmake 编译

/path/to/arm-qmake xxx.promake -j4

推送到板子

adb push myApp /root/

十四、最后做个总结

x86 到 ARM 交叉编译，表面上看是“编译不过”或者“程序运行失败”，但本质上，核心就三件事：

第一，分清主机和目标机

• Ubuntu 电脑是主机
• ARM 开发板是目标机

第二，分清本地编译和交叉编译

• 本地编译：给自己机器跑
• 交叉编译：给别的架构跑

第三，学会验证，而不是凭感觉猜

• 用 uname -m 看架构
• 用 file 看程序架构
• 用 qmake -v 看工具链
• 用实际日志判断是架构问题还是缺库问题

记住：

在 x86 主机上开发 ARM 程序，关键不是“能不能编出来”，而是“你到底用什么工具链，把它编成了谁的程序”。

十五、结尾

做嵌入式开发，最怕的不是报错，最怕的是“方向错了还一直努力”。

很多时候，程序上不了板，不是你代码写错了，而是你压根没把它编成板子能认识的样子。

先确认架构，再确认工具链，最后再谈业务逻辑。这一步想明白，交叉编译就不再神秘了。