说实话拿到RK3568开发板之后真正让人头疼的往往不是硬件本身而是软件环境。特别是你想在板子上跑Qt界面程序时第一步就卡在一个问题上怎么在Ubuntu上把Qt交叉编译环境搭起来还要能在Qt Creator里一键编译、一键部署、一键调试。这活儿我折腾过好几回踩过不少坑今天把整个流程整理成一篇能直接照着抄的文章从交叉编译原理、工具链选择、Qt源码编译到Qt Creator配置和远程调试一次说清楚。这个流程适合的目标读者很明确手上有RK3568开发板打算用Qt做嵌入式GUI宿主机是Ubuntu的开发者。不管你是刚接触嵌入式Linux的小白还是从单片机转过来的老手这篇文章都尽量讲得细致一些至少让你少走我当年走的弯路。1. 为什么要在Ubuntu上搭这套环境先搞清楚交叉编译的原理1.1 从x86到ARM交叉编译到底解决什么问题RK3568是瑞芯微旗下的一颗ARM64架构处理器核心是四核Cortex-A55。我们日常开发用的PC绝大多数是x86_64架构。x86和ARM是两套完全不同的指令集这就像一个是简体中文、一个是繁体中文虽然都认识但直接混着用是不行的。问题就来了在板子上直接编译Qt工程不现实。RK3568虽然能跑Linux但算力有限编译一两千个源文件的Qt库可能得等半天甚至更久而且板子上的存储一般也不宽裕。所以常规做法是在性能强劲的PC上用一套能生成ARM指令集程序的编译器来编译代码再把编译好的二进制拷到板子上运行。这个“在A架构上编译B架构程序”的过程就叫交叉编译。这里面有个关键概念需要先理解透彻交叉编译器不止是一个gcc/g那么简单。它背后是一整套工具链包括汇编器、链接器、C标准库头文件、glibc运行库等等它们共同决定了你能编出什么样的程序以及这个程序将来能在什么环境里跑。很多时候大家把交叉编译叫“工具链”原因就在这里。1.2 RK3568平台的特殊性工具链版本不是随便选的RK3568是ARMv8-A架构对应的是aarch64也就是64位ARM指令集。如果你拿一套32位的arm-linux-gnueabihf工具链去编译虽然也能编出ARM程序但不是针对RK3568优化的而且很多依赖库的系统路径、库文件都不对跑起来各种报错。所以第一步就要选对aarch64-linux-gnu这套64位工具链。工具链版本这事儿我多说一句。别不听劝就上最新的gcc 13、gcc 14我实测下来RK3568这类板子配套的官方SDK里通常自带工具链版本稳定在gcc 9.3到10.3之间。这个版本范围内的工具链和板子自带的glibc版本是能匹配的编译出来的程序放上去直接就能跑。如果你用太新的工具链很有可能编出来的程序在板子上报“version GLIBC_X.XX not found”然后你就要去折腾板子的rootfs降级那是真的痛。1.3 环境搭建的两条路线SDK工具链和独立工具链怎么选搭建交叉编译环境有两条路线我先说清楚你自己权衡。第一条路线是用厂商SDK自带的工具链。RK3568的开发板不少正点原子、迅为、飞凌这些都有配套SDK解压之后在prebuilts/gcc/linux-x86/aarch64/gcc-arm-10.3-x86_64-aarch64-none-linux-gnu/bin/路径下就能找到现成工具链。这种方式的好处是和板子的内核版本、库版本高度匹配基本不会出现跑不起来的问题缺点是路径藏得比较深环境变量得自己配。第二条路线是用ARM官方发布的工具链或者Linaro工具链自己去gcc.arm.com下载解压。这种路线的好处是版本选择灵活坏处是你要多花精力去匹配板子rootfs里的glibc版本。我个人的建议是如果你手头有厂商SDK优先用SDK里的项目一旦稳定下来版本就不要改了换来换去早晚出事。2. 基础环境准备Ubuntu、工具链与验证小实验2.1 宿主机需要装什么我默认你已经装好了Ubuntu系统。版本上20.04和22.04我都跑过都行。如果你用的是虚拟机建议给虚拟机分配至少4核CPU和8GB内存否则后面编译Qt源码在看片转圈的时候真的会怀疑人生。首先把基础工具装齐打开终端执行sudo apt update sudo apt install -y build-essential gdb-multiarch rsync ssh vim这四条命令分别做了什么事我说明一下build-essential包含编译必需的make、gcc、g等宿主机本地的编译环境得先立起来。gdb-multiarch一个跨架构的gdb调试器x86上调试ARM程序就靠它。很多教程会让你装aarch64-linux-gnu-gdb如果工具链包里没有用gdb-multiarch一样能干这活儿Qt Creator也能识别。rsync后面把板子的系统目录同步到宿主机以及文件部署都离不开它。ssh远程连接板子、执行命令上传文件的基础不装什么都干不了。额外提醒一个容易忽略的包libxkbcommon-dev。后面你编译Qt源码时如果开了xcb相关模块很容易因为缺少这个依赖直接报错。既然要搭环境就一步到位装好吧sudo apt install -y libxkbcommon-dev2.2 下载并配置ARM64交叉编译工具链不管你用哪条路线拿到工具链本质上都是一堆解压即用的文件。以SDK内举例假设工具链目录位于~/rk3568_sdk/prebuilts/gcc/linux-x86/aarch64/gcc-arm-10.3-x86_64-aarch64-none-linux-gnu我需要把它加进PATH里。我习惯在~/.bashrc末尾追加一段环境变量配置export RK_TOOLCHAIN~/rk3568_sdk/prebuilts/gcc/linux-x86/aarch64/gcc-arm-10.3-x86_64-aarch64-none-linux-gnu export PATH$RK_TOOLCHAIN/bin:$PATH然后执行source ~/.bashrc这里有个细节值得注意环境变量最好写在最后面不要覆盖系统原有的PATH。很多代码编译工具依赖宿主机的python、perl等解释器如果你把PATH里宿主机命令的优先级挤掉后面编译Qt源码时会冒出一堆莫名其妙的问题。2.3 用一个小程序验证工具链是否可用工具链配好只是第一步真金白银要经过火炼。写一个最简单的Hello World验证一下mkdir -p ~/rktest cd ~/rktest cat hello.c EOF #include stdio.h int main() { printf(Hello RK3568!\n); return 0; } EOF然后交叉编译aarch64-linux-gnu-gcc hello.c -o hello_arm file hello_arm如果输出中包含ELF 64-bit LSB executable, ARM aarch64这样的字样恭喜工具链基本没问题了。我习惯再用readelf -l hello_arm | grep interp看一眼程序依赖的动态链接器路径正常情况下应该是/lib/ld-linux-aarch64.so.1这能提前预判glibc兼容性问题。这个验证程序到后面还会用到先别删。3. Qt源码交叉编译整个过程最核心也是最磨人的一步3.1 为什么不能用apt直接装的Qt来交叉编译我知道很多新手习惯在Ubuntu上sudo apt install qt5-default这没问题但在交叉编译这个场景里完全行不通。用apt装的是面向x86宿主机编译好的二进制包它调用的qmake、Qt库都是x86指令集。你拿着这个qmake去编译ARM程序它会很认真地告诉你我只会编x86。所以交叉编译Qt必须走这条老路下载Qt官方源代码包用交叉工具链在x86机器上编译出一套ARM架构的Qt库这套库加上配套的qmake才是有资格参与RK3568交叉编译的完整工具链。这一步是整个搭建过程中最容易让人崩溃的环节因为Qt源码体量大、依赖面广你configure时候漏掉一个选项编译到一半才报错返工成本极高。我下面把每一步的关键参数和背后的原因都拆开讲。Qt的源码包我建议选qt-everywhere-src-5.15.2.tar.xz。5.15是LTS长期支持版本RK3568的嵌入式GUI场景下稳定性有保障。Qt6系列的configure参数变化较大不是不能用但网上参考案例少踩坑了你连个问的地方都不好找先把5.15跑通再说。解压源码mkdir -p ~/rk3568/qt cd ~/rk3568/qt tar xf qt-everywhere-src-5.15.2.tar.xz3.2 准备sysroot把板子的库同步到宿主机这是很多教程会一笔带过、但实际特别关键的一步。Qt交叉编译时编译器需要找到目标平台的头文件和库文件比如c标准库、tslib触摸库、各种Linux系统库。这些文件从哪里来答案是直接从开发板的rootfs里同步过来那套文件集合就叫sysroot。先在你的PC上建目录mkdir -p ~/rk3568/sysroot cd ~/rk3568/sysroot然后用rsync连接你的板子同步目录。我假设板子的IP是192.168.1.100用户名rootrsync -av root192.168.1.100:/lib . rsync -av root192.168.1.100:/usr/lib sysroot/usr/注意我这里是同步到sysroot/usr/子目录里因为工具链默认会去sysroot/usr/lib寻找库文件。操作完成后务必确认目录结构像这样~/rk3568/sysroot/ ├── lib └── usr └── lib有一个细节必须特别注意rsync同步的时候会保留符号链接这本身是好事但很多板子上的符号链接是指向绝对路径的比如/lib/aarch64-linux-gnu/libm.so.6 - /lib/aarch64-linux-gnu/libm-2.28.so到了宿主机上依然指向绝对路径结果就是工具链找不到文件。遇到这种情况我建议你在sysroot里手动创建一个从sysroot根目录到实际库目录的软链接或者干脆重新调整库文件目录把板子的/usr/lib/aarch64-linux-gnu整个同步进来。稳妥做法是rsync -av root192.168.1.100:/usr/lib/aarch64-linux-gnu sysroot/usr/lib/具体路径以你板子的实际目录为准先ssh到板子上用ls确认别想当然。如果你的应用还要用tslib触摸库检查一下板子上有没有/usr/include/tslib.h没有就得先把tslib编译安装到板子上再从板子同步。这属于前置依赖漏了后面Qt configure必然过不去。3.3 configure参数详解哪些项必须开、哪些项必须关进入Qt源码目录创建一个build目录独立编译这是我一直坚持的好习惯编译产物和源码分开以后清理非常方便cd ~/rk3568/qt/qt-everywhere-src-5.15.2 mkdir build cd build然后执行configure。下面这份配置是我在RK3568上经过多轮验证的可以直接拿来用../configure -prefix /opt/qt5.15.2-aarch64 \ -opensource -confirm-license \ -release \ -xplatform linux-aarch64-gnu-g \ -sysroot $HOME/rk3568/sysroot \ -linuxfb \ -eglfs \ -opengl es2 \ -tslib \ -no-xcb \ -no-openssl \ -skip qtwebengine \ -skip qtmultimedia \ -nomake examples -nomake tests每个关键项我都解释一下因为光会抄参数不行你得知道动了什么-prefix /opt/qt5.15.2-aarch64最终编译好的Qt库安装路径。这个路径是你宿主机的路径不是板子的。-xplatform linux-aarch64-gnu-g告诉Qt源码用哪个平台定义文件来编译。在源码的qtbase/mkspecs/目录下你会看到linux-aarch64-gnu-g这个文件夹里面是qmake.conf和qplatformdefs.h专门针对aarch64交叉编译写的。如果你的工具链前缀不是aarch64-linux-gnu这个mkspec可能也要微调但大多数情况直接用就行。-sysroot指向刚才同步的sysroot目录这是Qt交叉编译和宿主机编译最大的区别之一。有了它编译器才知道去哪里找头文件和库。-linuxfb -eglfs -opengl es2这三个是嵌入式Qt最常用的平台插件。RK3568有GPU支持Mali GPU的OpenGL ES 2.0编译进去之后程序就能用eglfs模式跑硬件加速也可退回到linuxfb纯软件渲染。两个都编进去运行时候用命令行切换灵活很多。-tslib如果你的板子用了电阻式触摸屏多数情况会外接tslib库这里打开选项Qt的linuxfb平台就能读取触摸事件。如果板子用的是电容触摸屏走的是evdev协议其实开不开tslib影响不大但我个人建议开到防止以后换屏麻烦。-no-xcbRK3568上跑Qt GUI主流是不跑桌面环境直接用framebuffer或EGLFS不需要X11更不需要xcb插件。关掉xcb能省一长串依赖省去很多不必要的烦恼。-no-openssl如果你的程序将来要跟HTTPS服务器交互这个选项要慎重关掉。但交叉编译OpenSSL本身是个独立工程且会把configure复杂度拉高一个数量级我建议第一版先关掉保平安后面有需求再单独编。-skip跳过一些在嵌入式场景下用不到的重量级模块qtwebengine编译起来能让你等到怀疑人生skip掉能大幅节省编译时间。configure执行完之后终端会显示一大堆配置总结。我每次都会在输出里找三个关键词linuxfb yes、eglfs yes、tslib yes。只要这三个都是yes后面编译基本就稳了。3.4 编译、安装和一次常被忽略的验证configure通过后真正的考验开始了。执行编译make -j$(nproc)这里的-j$(nproc)会自动把并发线程数设成CPU核心数。如果是在虚拟机上建议相对保守一点比如-j4否则内存不够的话编译到一半直接OOM被杀死前面的等待全部白费。编译完成后安装到指定prefix目录sudo make install为什么需要sudo因为/opt目录默认root权限而prefix指向那里。如果你不想用sudo也可以把prefix改成$HOME/qt5.15.2-aarch64这一层次可以自己定。装完后到/opt/qt5.15.2-aarch64/bin/目录下看一眼确认qmake文件存在。然后做一个最关键的验证执行/opt/qt5.15.2-aarch64/bin/qmake -query输出的QT_INSTALL_PREFIX应该指向 /opt/qt5.15.2-aarch64QMAKE_SPEC应该是linux-aarch64-gnu-g。如果这两个值不对后面Qt Creator里所有的自动查找都会乱套。我还习惯用这个qmake来编译一个最小Qt程序测试避免Qt库编完了但没法用的尴尬cd ~/rktest cat qt_test.cpp EOF #include QApplication #include QLabel int main(int argc, char *argv[]) { QApplication app(argc, argv); QLabel label(Qt on RK3568 OK!); label.show(); return app.exec(); } EOF用交叉qmake编译/opt/qt5.15.2-aarch64/bin/qmake -project /opt/qt5.15.2-aarch64/bin/qmake make如果这一步能顺利生成可执行文件且file qt_test显示aarch64说明Qt交叉编译环境核心链路已经打通了。4. Qt Creator配置把交叉编译环境“带劲”起来Qt库编好了但日常开发总不能命令行敲全套make吧接下来把这一切配置进Qt Creator让IDE自动完成编译、部署、调试这才能谈开发效率。4.1 配置交叉编译器与调试器打开Qt Creator进入Tools - Options - Kits。左侧选Compilers点击Add - GCC - C在Compiler path里选择工具链bin目录下的aarch64-linux-gnu-gcc。按同样操作添加C编译器选择aarch64-linux-gnu-g。这里我要重点提醒一个界面细节Qt Creator的编译器配置页里有个ABI下拉框很多时候自动识别成Generic会导致后面的Kit识别不了。你应该手动把ABI设置成arm-linux-generic-elf-64bit不行的话就选aarch64-linux-generic-elf-64bit。这一步是很多新手第一次配Kit失败的直接原因。接着切到Debuggers标签页点Add - GDB如果工具链bin下有aarch64-linux-gnu-gdb直接选它。如果用的是缩水版工具链没有就用系统装好的/usr/bin/gdb-multiarch。两个都能跑但注意gdb-multiarch需要你在启动调试前手动指定目标架构Qt Creator 新版本一般会自动带上老版本偶尔会忘到时我下面调试环节再讲怎么处理。4.2 添加Qt版本与qmake路径在同一个Kits窗口中切到Qt Versions点击Add选择/opt/qt5.15.2-aarch64/bin/qmake。确认后在下方显示“Qt 5.15.2 (qt5.15.2-aarch64)”就说明识别成功了。这里有第二个坑Qt Creator 会尝试运行qmake -query来获取Qt的信息如果你的PATH环境变量在GUI启动时没加载qmake相关路径可能显示“Error”。解决办法不是去改环境变量因为GUI环境不一定读取.bashrc而是直接用按钮切换到/opt/qt5.15.2-aarch64/bin/qmake这个绝对路径通常情况下它会重新运行查询并恢复。4.3 配置远程设备与Kit把三者串起来还是在这个窗口切到Devices标签页点击Add选择Generic Linux Device。填写NameRK3568 BoardHost name192.168.1.100UsernamerootPassword你板子的root密码默认一般是rockchip配置完成后Qt Creator会尝试通过ssh连接板子并在启动时做连通性测试。这一步如果失败优先检查板子的SSH服务是否开启命令是sudo systemctl status sshd如果没有就在板子上安装或自启动sudo systemctl enable ssh最后回到Kits标签页点击Add新建一个Kit取名叫RK3568 Qt 5.15.2然后在各个下拉框里选CompilerC和C都选刚才添加的RK3568 GCC/GDebugger选刚加的gdbQt version选5.15.2-aarch64Device typeGeneric Linux DeviceDeviceRK3568 BoardSysroot填~/rk3568/sysroot注意Sysroot这项必须填否则你将来在Qt Creator里打开Qt的头文件、查看Qt库源码时会定位到宿主机的Qt头文件最后看到的源码根本对不上调试信息也会乱一截。4.4 新建一个测试工程验证整套链路在Qt Creator里新建一个Qt Widgets Application把构建套件选成刚配好的RK3568 Qt 5.15.2。写一个简单界面然后直接点左下角的“构建”按钮。如果构建顺利会生成一个aarch64架构的二进制。部署到板子上有两种方式一种是直接用Qt Creator的部署功能在Projects - Run页面里配置部署步骤勾选“Upload files via SFTP”之类的选项。这个方式适合文件量少的场景。另一种是我个人偏爱的命令行手动scp。原因很简单部署到嵌入式板子时你还需要把整个Qt运行库上传过去那是一个大目录IDE的部署功能处理起来既慢又容易遗漏。scp ./qt_test root192.168.1.100:/root/ scp -r /opt/qt5.15.2-aarch64/lib root192.168.1.100:/opt/qt5.15.2-aarch64/上传完库文件后在板子上设置环境变量export LD_LIBRARY_PATH/opt/qt5.15.2-aarch64/lib:$LD_LIBRARY_PATH export QT_QPA_PLATFORMlinuxfb然后运行./qt_test看到板子屏幕上出现“Qt on RK3568 OK!”的窗口这一步通关。5. 远程部署与调试实操在板子上能看到界面是一回事能用Qt Creator断点调试代码又是另一回事。嵌入式开发最痛苦的时刻就是程序崩了却只知道printf一行行加。远程调试能很大程度缓解这个问题。5.1 部署机制rsync同步、权限与依赖处理上面提到了用scp上传文件但实际项目越做越大文件越改越频繁scp就变得不高效了。我给一个更省心的方案用rsync做增量同步。在宿主机上写一个简单的部署脚本deploy.sh#!/bin/bash rsync -avz --progress \ --exclude*.o --exclude*.user \ ./build/rk3568/your_app root192.168.1.100:/root/app/每次编译完后执行一下脚本只有变更的文件会被传上去带宽和时间节省非常明显。同时记得脚本里加上--exclude把不需要的对象文件排除掉。还有个必须养成习惯的点板子上的库依赖。如果Qt程序依赖/opt/qt5.15.2-aarch64/lib下的动态库你在板子上运行前必须确认环境变量export LD_LIBRARY_PATH/opt/qt5.15.2-aarch64/lib:$LD_LIBRARY_PATH每次ssh登进去都要重设很烦。推荐直接把这一行写进板子的/etc/profile里一劳永逸。5.2 在开发板上准备gdbserver远程调试的架构是板子上跑一个轻量gdbserver程序负责接收调试指令并控制目标进程宿主机上由gdbQt Creator 内置通过网络发送调试指令。两边可以不同架构gdbserver是ARM版gdb是x86版但它们之间通过调试协议通信架构无关。Ubuntu的apt源里不一定有aarch64版的gdbserver所以推荐在板子上直接安装apt update apt install gdbserver安装完成后验证一下gdbserver --version如果板子的rootfs里面没有apt源或者装不上还有一个办法直接从宿主机工具链SDK里拷贝。很多工具链自带一个aarch64-linux-gnu-gdbserver路径在bin目录下把它scp到板子上用就行。5.3 Qt Creator远程调试设置细节路径映射与运行环境变量回到Qt Creator先配置Run选项。在Projects - Run页面里把Run locally取消掉勾选Run on device设备选RK3568 Board。这样Qt Creator会通过SSH在板子上启动程序并且能够自动接入调试器。这里有一个特别常见的问题Qt Creator通过device启动程序时运行环境变量跟板子上手动设置的不一样。你必须在Run页面下方的Run Environment里手动添加键值LD_LIBRARY_PATH/opt/qt5.15.2-aarch64/lib:$LD_LIBRARY_PATHQT_QPA_PLATFORMlinuxfb不配好这两项你在Qt Creator里一点调试按钮程序在板子上可能还没跑到main()就崩了报错信息还特别隐晦说的是“加载共享库失败”之类的让人一头雾水。接着配置路径映射。调试的本质是拿板子上的符号信息跟宿主机上的源码做匹配。你在宿主机用/home/oem/RK3568_Qt/hello/main.cpp这个路径打开源码但板子上gcc编译出来的调试符号里记录的是板子上的编译路径两者对不上断点就打不上。解决方法是Tools - Options - Debugger - General - Source Paths Mapping里添加一条映射比如/opt/qt5.15.2-aarch64 - /home/oem/RK3568_Qt/hello如果你整个工程都放在固定路径下也可以在项目设置 - Debugger Settings - Debugger里单独配置作用域更精确。配置完成后整体流程就是写好代码点编译Qt Creator自动上传到板子调用gdbserver启动进程宿主机连接上去然后就可以像调试本地程序一样加断点、看变量、看调用栈。有一点要提醒嵌入式远程调试比本地调试多了一个网络延迟单步执行会有肉眼可见的卡顿这是正常的不是你的电脑坏了。我在实际开发中一般用远程调试来定位崩溃和逻辑bug性能调优则靠打印日志辅助两者结合效率最高。6. 踩坑实录高频问题与排查思路速查环境搭建类的话题光讲流程不讲坑等于白讲。这节我把这些年遇到过的典型问题整理成一个速查表按阶段分类方便你到时候直接翻。6.1 编译阶段的常见报错报错信息原因分析解决思路cannot find -ltssysroot里没有tslib库文件在板子上安装libts-dev重新同步sysrootGL/gl.h: No such file or directory缺少OpenGL相关头文件检查sysroot的usr/include里有没有mesa、GLES头文件必要时同步板子的/usr/includeqatomic.h: No such filesysroot不完整Qt版本和头文件mismatch重做sysroot同步确保目录结构完整error: unknown type name ‘bool’编译器参数或C语言标准问题检查是否在纯C文件中混编了C代码用g编译libQt5Core.so: undefined reference todlopenGLIBC_2.x板子的glibc版本太老工具链太新换用更低版本工具链或升级板子rootfs编译阶段还有一个很典型的坑make -j6 时编译到一半突然报internal compiler error: Killed (program cc1plus)这是内存不足把编译器杀了。解决办法是减少并行线程数或者给虚拟机多分配内存没有别的捷径。6.2 运行阶段的高频问题程序编译出来了拷到板子上跑报错也是五花八门。我把最常见的几种列出来报错信息原因分析解决思路application could not be executed二进制格式不对用file检查文件头确认是ELF 64-bit ARM aarch64error while loading shared libraries: libstdc.so.6缺少C运行库把/opt/qt5.15.2-aarch64/lib和板子上的/usr/lib相应对齐确认工具链的库都部署了The wayland display couldnt be opened默认走了wayland平台插件显式设置QT_QPA_PLATFORMlinuxfb或eglfscould not find or load the Qt platform plugin xcb之前configure开了xcb选项但相关依赖缺失运行时设置QT_QPA_PLATFORMlinuxfb或者重新编译时加-no-xcb这里我要重点说下QT_QPA_PLATFORM这个东西。Qt从5.0开始抽象出一层QPAQt Platform Abstraction它在运行时决定Qt怎么跟底层显示系统交互。在开发板上最保险的启动方式就是先设成linuxfb它走Linux framebuffer不依赖任何显示服务兼容性最强。如果你在板子上装了完整的桌面环境想跑在X11下面才需要设置成xcb。而在RK3568上如果想调用GPU硬件加速设成eglfs会是最佳选择但前提是Mali驱动已经正确加载且你的Qt编译时带了-eglfs选项。6.3 远程调试阶段的常见坑现象原因分析解决思路点击调试后Qt Creator卡在“Connecting to server”板子上gdbserver没启动或端口被防火墙挡了先手动在板子上启动gdbserver :2345确认能连断点显示灰色提示“not valid at this line”源码路径映射没配好或有优化release编译导致行号错位检查Debugger的Source Paths Mapping改成release为debug断点命中后看不到变量值编译时没加调试符号确保编译时是debug模式qmake工程中CONFIG debug调试器报“Remote connection closed”gdbserver崩溃或板子掉线查看板子端gdbserver的日志确认程序没有在启动阶段直接segfault单步调试卡死网络延迟或同步点卡住减少单步频率多在不常变化的行打断点跳着走远程调试还有一个特殊情况如果你的程序在main()之前就崩了比如动态链接库加载失败Qt Creator的调试器是不好抓到的。这时候我会在板子上手动执行gdbserver :2345 ./your_app然后在宿主机用gdb attach上去用info sharedlibrary查看哪些库没加载往往能飞快定位到缺失依赖。整个环境搭好之后日常开发就进入一个相对舒服的节奏宿主机写代码、编译、一键部署、远程调试板子上的逻辑用断点和日志并行定位。这套流程我现在用得很顺手但前期的坑也算踩了个遍。说实话如果让我重来一次我会在下载Qt源码之前先把板子上的glibc版本、tslib依赖、工具链版本这三角关系理清楚能省下非常多返工时间。希望这篇文章能帮你把这段路走得顺一点。