龙架构双周会第 42 期一个持续运转的生态信号与开发者入局指南“龙架构双周会第 42 期”这个标题如果放在两年前可能还只是一个小圈子里的技术例会。但当它稳步走到第 42 期时间进入 2026 年 8 月这件事本身就已经释放了一个明确信号LoongArch 不再停留在“要不要支持”的讨论阶段而是进入了“如何支持得更好”的常态化生态建设期。这篇文章不打算逐条转述双周会的具体议程——那需要以官方发布内容为准。我更想借这个时间窗口帮关注龙架构的开发者理清三件事LoongArch 现在的技术底座到底在哪一层、你想以最低成本跑起来有哪些路径、真正参与生态建设应该从哪些具体动作开始。读完你会知道体验一个非 x86 指令集架构并没有想象中那么重难点也不在“装系统”而在后面那些工程化适配意识。1. 第 42 期意味着什么双周会背后的生态信号双周会顾名思义是每两周一次的技术例会。这种节奏本身比单期内容更有分析价值。在软件生态建设里会议机制是最容易被低估的基础设施。一次技术大会可以热闹一整天但真正决定生态推进速度的往往是“有没有一个固定频率的对话场所”。龙架构双周会能持续办到第 42 期至少说明三件事第一龙架构生态已经具备持续的信息输入和输出通道。每一期涉及内核、编译器、基础软件、社区用户反馈等议题这些议题能按固定节奏被讨论意味着生态不是“发布完就散场”而是有长期维护结构的。第二社区参与者的身份正在发生变化。早期关注一个指令集架构的人大多是评估者、观望者而当会议持续到几十期之后继续留在场内的已经变成了实际动手做适配、做移植、做优化的开发者。这两种身份对生态的推动力完全不同。第三对开发者而言双周会是一个可预期的信息源。你不需要每天盯着各种零散新闻只要按节奏跟进就能掌握工具链更新、已知问题、软件适配进度、用户反馈等关键信息。这在技术选型时是非常有用的决策输入。从时间跨度看按双周一次估算从第 1 期走到第 42 期已经有相当长一段时间。这样一个持续运转的会议机制比任何单点发布都更能说明龙架构生态正在进入“日常化推进”阶段。对于还没动手的开发者当前恰恰是一个不错的入场观察窗口生态既有一定成熟度又还处于需要大量人手参与适配的阶段。2. 龙架构的核心技术与生态现状要理解龙架构的潜力与边界得先搞清楚它在技术栈中的位置。2.1 指令集层面LoongArch 的定义与特点LoongArch 是龙芯中科推出的指令集架构它不是基于某个现成指令集的简单修改而是一套自主设计的指令集。从 2020 年左右正式公布以来它经历了从基础指令集定义、扩展指令集完善到逐步形成 32 位和 64 位体系的过程。这里需要区分两个概念指令集架构ISA和微架构实现。指令集是软件与硬件之间的“契约”决定了一个编译好的程序能在什么样的 CPU 上运行微架构则是具体的电路实现方式。LoongArch 的自主性主要体现在 ISA 定义权上而基于 LoongArch 的处理器比如大家熟悉的 3A5000、3A6000 系列则是具体的微架构产品。从技术特征上看LoongArch 属于 RISC 风格指令集拥有规整的指令编码、通用寄存器结构和清晰的扩展机制。这种设计思路决定了它对编译器、操作系统、上层软件的支持逻辑与 x86、ARM 会有明显差异但在工程方法论上是共通的。2.2 二进制翻译过渡期的关键能力龙架构生态目前面临的最大现实问题不是指令集本身不够好而是存量软件生态主要以 x86 为中心。为了让 Linux 桌面和服务器场景中的既有应用能跑起来二进制翻译技术LoongArch 下的 LATLoongArch Translator就成了一个非常关键的过渡方案。简单理解二进制翻译是在运行时把 x86 指令动态翻译成龙架构指令。这个方案的优点是可以降低用户切换架构时的阵痛让一些暂时没有原生版本的软件能先“用起来”。但它也有明显代价性能损耗、兼容性边界、调试困难。所以二进制翻译是“过渡桥梁”不是“终点方案”。真正健康的生态最终依赖的是大量软件的原生适配。2.3 当前生态版图哪些已经可用经常有人问龙架构现在到底能干什么从公开信息看以下几条线已经积累了相当基础操作系统统信、麒麟以及多款开源 Linux 发行版都有龙架构版本Linux 内核主线的龙架构支持已经相当成熟。编译器与工具链GCC、LLVM/Clang、binutils 等主要工具链都已支持 LoongArch这是生态的“地基中的地基”。基础运行时JavaOpenJDK、Python、Node.js、Go、Rust 等常见语言运行时都有龙架构适配进展。数据库与中间件部分主流数据库、消息队列、Web 服务器在龙架构上有过适配和运行实践。桌面与办公常见桌面环境、办公软件、浏览器等应用场景已经有可用版本。当然生态完善程度与 x86 相比仍有差距这是客观事实。如果用一句话概括当前生态状态服务器端和基础设施软件的基础已经铺开应用层长尾仍在快速补齐。这也意味着越早参与龙架构适配的开发者越容易在生态成熟过程中积累经验红利。3. 开发者上手龙架构的三种最低成本路径如果你还没有龙芯硬件想先体验 LoongArch 环境大致有三条路径。它们的成本、真实度和适用场景各不相同。路径需要硬件上手速度真实度适合场景QEMU 模拟不需要快中高学习指令集、测试系统、软件适配预研云实例或开发板开发板需要云实例不需要中等高长期开发、性能敏感任务、部署测试容器/多架构构建不需要快中构建多架构镜像、CI 适配、验证软件兼容性三条路径之间不是互斥关系。实际工程中很多人是先用 QEMU 和容器做“能不能跑”的预研确认可行后再上开发板或真实服务器做“跑得好不好”的验证。建议初学阶段按“先模拟、后硬件”的顺序推进。4. 用 QEMU 跑通 LoongArch 环境完整示例QEMU 是目前体验 LoongArch 最方便的方式。它用软件模拟完整的 CPU 和外设让你不需要任何真实硬件就能启动一个 LoongArch 系统。4.1 环境准备首先在宿主机上安装 QEMU。不同发行版的安装命令略有差异# Debian / Ubuntu 系列 sudo apt install qemu-system-misc qemu-utils # Fedora / RHEL 系列 sudo dnf install qemu-system-loongarch64在 Debian/Ubuntu 上龙架构的 QEMU 支持通常包含在qemu-system-misc包里。装完后你可以用下面的命令确认本机 QEMU 是否认识龙架构qemu-system-loongarch64 --version如果能正常输出版本号说明 QEMU 可执行文件已就绪。4.2 获取系统镜像这一步是整个流程中最容易卡住的地方因为不同发行版提供的龙架构镜像格式、启动参数和默认配置都不完全一样。稳妥的做法是去你熟悉的 Linux 发行版官网查找是否有 LoongArch64 架构的系统镜像。优先选择官方提供的 QEMU 镜像或安装镜像。关注镜像说明中的启动参数和登录账号。这里不列出单一固定下载地址因为镜像下载链接变化较快而且不同镜像需要的启动命令确实存在差异。4.3 启动 QEMU 虚拟机拿到镜像后可以用类似下面的命令启动。这个命令是一个通用模板实际参数需要根据镜像说明调整qemu-system-loongarch64 \ -m 4G \ -smp 4 \ -machine virt \ -cpu LoongArch-virt \ -drive fileloongarch64.qcow2,formatqcow2,ifvirtio \ -netdev user,idnet0 \ -device virtio-net-pci,netdevnet0 \ -display default参数含义如下-m 4G给虚拟机分配 4GB 内存。-smp 4分配 4 个虚拟 CPU。-machine virt使用 QEMU 为龙架构提供的 virt 虚拟机器。不同版本的 QEMU 支持的 machine 名称可能不同如果提示找不到可以执行qemu-system-loongarch64 -machine help查看当前版本支持的列表。-cpu LoongArch-virt指定虚拟 CPU 型号。-drive fileloongarch64.qcow2,formatqcow2,ifvirtio挂载系统磁盘镜像。qcow2是 QEMU 常用的镜像格式不解包、占用空间小、支持快照。-netdev user,idnet0和-device virtio-net-pci,netdevnet0为用户模式网络连接创建虚拟网卡这样虚拟机内部可以访问外网。-display default如果是在有图形界面的环境会弹出虚拟机窗口在纯服务器环境可以改成-nographic使用串口控制台。4.4 验证系统是否启动成功系统启动并登录后第一步应该执行uname -m如果一切正常输出结果是loongarch64看到这个输出说明你已经在 LoongArch 指令集环境下运行命令了。接下来可以继续验证 CPU 信息cat /proc/cpuinfo | head -n 20这里会显示当前虚拟 CPU 的型号、feature 等信息能帮助你确认内核是否以龙架构模式启动。4.5 常见启动问题如果你执行启动命令后黑屏或报错优先检查三点QEMU 版本是否支持龙架构。较老版本的 QEMU 可能没有qemu-system-loongarch64。-machine和-cpu参数是否匹配镜像要求。不同镜像对虚拟硬件的要求不同。磁盘镜像路径是否正确以及当前用户是否有读取权限。QEMU 跑通的意义不只是“装了个系统”而是给你一个安全、可快照、可随时销毁的实验环境。后续做内核实验、软件交叉编译测试、系统级调试都可以在这个环境里先跑一遍。5. 容器与多架构构建loong64 的工程化实践在真实工程中很多人接触 LoongArch 不是因为买了龙芯电脑而是因为要在 CI 流水线里构建多架构镜像或者在容器环境里验证自己的软件能否在 loong64 上运行。5.1 认识多架构镜像容器镜像可以支持多个 CPU 架构。Docker 的 manifest list 机制允许同一个镜像名对应多个平台的镜像Docker 会根据运行环境的 CPU 架构自动拉取对应版本。龙架构在 Docker 生态中的平台标识通常是linux/loong64这个标识可以在需要手动指定平台时使用。例如查看某个镜像是否提供了龙架构版本docker buildx imagetools inspect --raw 镜像名:标签不过这个命令输出的原始 manifest 内容对新手不太友好。更直观的做法是直接尝试以龙架构平台拉取镜像看是否报错。5.2 使用 buildx 构建 loong64 镜像假设你有一个简单的 C 程序想在龙架构上以容器方式运行。这里提供一个不需要依赖任何基础镜像的简化版 Dockerfile# Dockerfile FROM scratch COPY hello-loongarch64 /hello ENTRYPOINT [/hello]这个镜像只包含一个静态编译的 LoongArch 可执行文件。FROM scratch表示空镜像没有任何系统库因此hello-loongarch64必须是静态编译的。构建命令docker buildx build --platform linux/loong64 -t example/hello:loong64 .这里的关键是--platform linux/loong64它告诉 buildx 我要构建面向龙架构的镜像。如果你的 Docker 环境没有启用 buildx可以先用docker buildx ls查看。构建完成后如果想在非龙架构机器上直接运行这个镜像通常会遇到exec format error因为 CPU 无法执行异构指令。这时需要借助 QEMU 的用户态模拟来运行或者把镜像推到支持龙架构的服务器上运行。5.3 工程中的注意事项在实际项目中多架构构建有一个经常被忽略的坑不是所有基础镜像都提供 loong64 版本。很多存量镜像只有 amd64 和 arm64 版本这会直接导致构建失败。因此在选择基础镜像时需要提前确认这个官方镜像是否发布 loong64 / loongarch64 变体如果还没有能否用FROM scratch或自建基础镜像解决需要用到哪些系统库龙架构的软件源里是否都有对应版本容器化的优势在于它把“系统环境”固化成构建产物一旦适配跑通就能批量分发。这也是龙架构生态建设中最值得投入的方向之一。6. 源码适配与交叉编译基础如果你手头有一个开源项目想要支持龙架构核心工作往往集中在编译环节。这里需要理解“交叉编译”和“原生编译”的区别。6.1 什么是交叉编译交叉编译是在一台机器上编译出能在另一种架构上运行的程序。比如你在 x86 的电脑上编译出一个 LoongArch 的可执行文件。对比一下原生编译在龙架构机器上编译龙架构程序产物直接在本机运行。交叉编译在非龙架构机器上编译龙架构程序产物需要拷贝到龙架构机器或模拟环境中运行。交叉编译的优势是可以复用你现有的 CI 机器和开发环境痛点在于需要维护一套交叉编译工具链并且一些构建脚本会默认在当前平台编译本地工具导致交叉编译经常失败。6.2 从源码到 loong64 可执行文件这里以一个最简单的 C 程序为例。我们先写一个hello.c#include stdio.h int main(void) { printf(Hello LoongArch!\n); return 0; }在 Debian/Ubuntu 系列发行版上可以通过包管理器搜索龙架构相关的交叉编译工具链apt search loongarch64搜索到对应工具链包后安装。安装完成后交叉编译命令类似loongarch64-linux-gnu-gcc -static -o hello-loongarch64 hello.c然后查看生成文件的架构信息file hello-loongarch64正常情况下输出中会包含类似LoongArch 64-bit的描述hello-loongarch64: ELF 64-bit LSB executable, LoongArch 64-bit, ...如果在自己的机器上无法运行这个文件可以把它拷贝到 QEMU 虚拟机或龙架构服务器上运行。静态编译的好处就在这里它不依赖目标系统上的动态库拷过去直接就能跑。6.3 构建脚本与配置的适配思路对于稍微复杂一点的项目直接改编译命令往往不够还需要处理构建系统配置。以 CMake 为例常见思路是编写一个龙架构工具链文件# loongarch64-toolchain.cmake set(CMAKE_SYSTEM_NAME Linux) set(CMAKE_SYSTEM_PROCESSOR loongarch64) set(CMAKE_C_COMPILER loongarch64-linux-gnu-gcc) set(CMAKE_CXX_COMPILER loongarch64-linux-gnu-g) set(CMAKE_FIND_ROOT_PATH /usr/loongarch64-linux-gnu) set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)使用时通过-DCMAKE_TOOLCHAIN_FILE指定cmake -DCMAKE_TOOLCHAIN_FILEloongarch64-toolchain.cmake .. make这个文件的核心是告诉 CMake目标系统是 Linux loongarch64编译器用交叉编译器查找库和头文件时只去交叉编译根目录找不要误用到本机 x86 的库。真正的适配难点也在这里很多大型项目会有arch相关的内联汇编、CPU feature 检测、优化选项需要逐个处理。这个过程没有捷径但一旦沉淀下来就是非常宝贵的生态资产。7. 常见问题与排查思路在龙架构环境的搭建和适配过程中有几个问题出现频率非常高。这里整理成一张排查表方便快速定位。问题现象可能原因排查方式解决方案QEMU 启动黑屏或无输出镜像架构与 QEMU 配置不匹配查看 QEMU 日志确认 machine/cpu 参数执行qemu-system-loongarch64 -machine help查看可用配置按镜像说明调整uname -m输出不是loongarch64启动的内核或系统版本不对在虚拟机内执行cat /proc/cpuinfo确认使用的是龙架构内核镜像及配套根文件系统Docker 运行报exec format error镜像架构与当前平台不匹配执行docker image inspect 镜像名查看 Architecture 字段使用--platform linux/loong64拉取或在龙架构机器上运行交叉编译产物在目标机上段错误动态链接库缺失或版本不匹配在目标机执行ldd ./程序改用-static静态编译或在目标机安装对应动态库CMake 找到本机 x86 库工具链文件未正确设置查找路径查看 CMake 输出的库路径检查CMAKE_FIND_ROOT_PATH确保库查找范围被限制源码中检测不到龙架构构建脚本缺少 LoongArch 平台分支搜索源码中的x86_64、aarch64等平台判断逻辑在对应判断逻辑中补充loongarch64分支二进制翻译运行 x86 应用性能低翻译执行本身就存在开销对比原生版本与翻译版本耗时优先寻找或打包该软件的原生龙架构版本遇到问题时的排查顺序建议永远是“先确认架构再看日志最后怀疑逻辑错误”。架构不匹配是最常见、最容易被忽略的起点。8. 从体验到贡献给开发者的实践建议如果你已经跑通了 QEMU 或容器环境下一步的关键是“别停留在体验层”。这里给出几条可执行的路径按照难度从低到高排列第一把你的常用工具链在龙架构环境里完整跑一遍。不需要选复杂项目就从 Python、Node.js、GCC 这些最基础的开始记录哪些能跑、哪些缺少依赖、哪些有报错。这些记录本身就是价值。第二挑一个你熟悉的小项目做适配测试。找那种依赖不太多、构建逻辑简单的工具库或命令行程序试着在龙架构环境里源码编译。遇到报错就修修的过程就是你理解项目构建逻辑的过程。第三关注双周会的技术议题带着问题参与。如果你已经在某个环节遇到具体障碍可以把问题整理成清晰的描述在社区渠道提出。技术会议最有价值的参与方式不是当听众而是提有效的技术问题。第四把适配经验沉淀为补丁和文档。开源软件适配龙架构最终要走到上游社区。你可以提交 PR、提交 bug report、补充构建文档。这些动作看起来不大但正是生态建设最稀缺的“最后一公里”。要注意的是龙架构生态处于上升期意味着边界在快速变化。半年前不可用的软件现在可能已经有原生版本上一季度的构建方法下个季度可能有更优解。保持持续跟进比一次性搞懂更重要。9. 总结从龙架构双周会第 42 期这个坐标点往回看LoongArch 已经走过了指令集定义、基础工具链适配、操作系统接入这几个关键阶段当前最值得关注的是应用层长尾软件和工程化基础设施的完善速度。对开发者来说现在入局的门槛并不高没有硬件用 QEMU 和 Docker 同样可以完成大量预研和适配工作需要的不是特别高深的技术而是耐心排查构建问题的工程能力。以后再有人问“龙架构能用了吗”更准确的回答方式是先问清楚他要在什么场景用——做服务器、做桌面、跑容器、还是做嵌入式。不同场景的生态成熟度差异很大。这也是双周会这类社区机制能持续存在的价值所在它让这些问题有地方被持续讨论并且让每个参与者的经验能沉淀下来成为整个生态的公共资产。
龙架构双周会第 42 期一个持续运转的生态信号与开发者入局指南“龙架构双周会第 42 期”这个标题如果放在两年前可能还只是一个小圈子里的技术例会。但当它稳步走到第 42 期时间进入 2026 年 8 月这件事本身就已经释放了一个明确信号LoongArch 不再停留在“要不要支持”的讨论阶段而是进入了“如何支持得更好”的常态化生态建设期。这篇文章不打算逐条转述双周会的具体议程——那需要以官方发布内容为准。我更想借这个时间窗口帮关注龙架构的开发者理清三件事LoongArch 现在的技术底座到底在哪一层、你想以最低成本跑起来有哪些路径、真正参与生态建设应该从哪些具体动作开始。读完你会知道体验一个非 x86 指令集架构并没有想象中那么重难点也不在“装系统”而在后面那些工程化适配意识。1. 第 42 期意味着什么双周会背后的生态信号双周会顾名思义是每两周一次的技术例会。这种节奏本身比单期内容更有分析价值。在软件生态建设里会议机制是最容易被低估的基础设施。一次技术大会可以热闹一整天但真正决定生态推进速度的往往是“有没有一个固定频率的对话场所”。龙架构双周会能持续办到第 42 期至少说明三件事第一龙架构生态已经具备持续的信息输入和输出通道。每一期涉及内核、编译器、基础软件、社区用户反馈等议题这些议题能按固定节奏被讨论意味着生态不是“发布完就散场”而是有长期维护结构的。第二社区参与者的身份正在发生变化。早期关注一个指令集架构的人大多是评估者、观望者而当会议持续到几十期之后继续留在场内的已经变成了实际动手做适配、做移植、做优化的开发者。这两种身份对生态的推动力完全不同。第三对开发者而言双周会是一个可预期的信息源。你不需要每天盯着各种零散新闻只要按节奏跟进就能掌握工具链更新、已知问题、软件适配进度、用户反馈等关键信息。这在技术选型时是非常有用的决策输入。从时间跨度看按双周一次估算从第 1 期走到第 42 期已经有相当长一段时间。这样一个持续运转的会议机制比任何单点发布都更能说明龙架构生态正在进入“日常化推进”阶段。对于还没动手的开发者当前恰恰是一个不错的入场观察窗口生态既有一定成熟度又还处于需要大量人手参与适配的阶段。2. 龙架构的核心技术与生态现状要理解龙架构的潜力与边界得先搞清楚它在技术栈中的位置。2.1 指令集层面LoongArch 的定义与特点LoongArch 是龙芯中科推出的指令集架构它不是基于某个现成指令集的简单修改而是一套自主设计的指令集。从 2020 年左右正式公布以来它经历了从基础指令集定义、扩展指令集完善到逐步形成 32 位和 64 位体系的过程。这里需要区分两个概念指令集架构ISA和微架构实现。指令集是软件与硬件之间的“契约”决定了一个编译好的程序能在什么样的 CPU 上运行微架构则是具体的电路实现方式。LoongArch 的自主性主要体现在 ISA 定义权上而基于 LoongArch 的处理器比如大家熟悉的 3A5000、3A6000 系列则是具体的微架构产品。从技术特征上看LoongArch 属于 RISC 风格指令集拥有规整的指令编码、通用寄存器结构和清晰的扩展机制。这种设计思路决定了它对编译器、操作系统、上层软件的支持逻辑与 x86、ARM 会有明显差异但在工程方法论上是共通的。2.2 二进制翻译过渡期的关键能力龙架构生态目前面临的最大现实问题不是指令集本身不够好而是存量软件生态主要以 x86 为中心。为了让 Linux 桌面和服务器场景中的既有应用能跑起来二进制翻译技术LoongArch 下的 LATLoongArch Translator就成了一个非常关键的过渡方案。简单理解二进制翻译是在运行时把 x86 指令动态翻译成龙架构指令。这个方案的优点是可以降低用户切换架构时的阵痛让一些暂时没有原生版本的软件能先“用起来”。但它也有明显代价性能损耗、兼容性边界、调试困难。所以二进制翻译是“过渡桥梁”不是“终点方案”。真正健康的生态最终依赖的是大量软件的原生适配。2.3 当前生态版图哪些已经可用经常有人问龙架构现在到底能干什么从公开信息看以下几条线已经积累了相当基础操作系统统信、麒麟以及多款开源 Linux 发行版都有龙架构版本Linux 内核主线的龙架构支持已经相当成熟。编译器与工具链GCC、LLVM/Clang、binutils 等主要工具链都已支持 LoongArch这是生态的“地基中的地基”。基础运行时JavaOpenJDK、Python、Node.js、Go、Rust 等常见语言运行时都有龙架构适配进展。数据库与中间件部分主流数据库、消息队列、Web 服务器在龙架构上有过适配和运行实践。桌面与办公常见桌面环境、办公软件、浏览器等应用场景已经有可用版本。当然生态完善程度与 x86 相比仍有差距这是客观事实。如果用一句话概括当前生态状态服务器端和基础设施软件的基础已经铺开应用层长尾仍在快速补齐。这也意味着越早参与龙架构适配的开发者越容易在生态成熟过程中积累经验红利。3. 开发者上手龙架构的三种最低成本路径如果你还没有龙芯硬件想先体验 LoongArch 环境大致有三条路径。它们的成本、真实度和适用场景各不相同。路径需要硬件上手速度真实度适合场景QEMU 模拟不需要快中高学习指令集、测试系统、软件适配预研云实例或开发板开发板需要云实例不需要中等高长期开发、性能敏感任务、部署测试容器/多架构构建不需要快中构建多架构镜像、CI 适配、验证软件兼容性三条路径之间不是互斥关系。实际工程中很多人是先用 QEMU 和容器做“能不能跑”的预研确认可行后再上开发板或真实服务器做“跑得好不好”的验证。建议初学阶段按“先模拟、后硬件”的顺序推进。4. 用 QEMU 跑通 LoongArch 环境完整示例QEMU 是目前体验 LoongArch 最方便的方式。它用软件模拟完整的 CPU 和外设让你不需要任何真实硬件就能启动一个 LoongArch 系统。4.1 环境准备首先在宿主机上安装 QEMU。不同发行版的安装命令略有差异# Debian / Ubuntu 系列 sudo apt install qemu-system-misc qemu-utils # Fedora / RHEL 系列 sudo dnf install qemu-system-loongarch64在 Debian/Ubuntu 上龙架构的 QEMU 支持通常包含在qemu-system-misc包里。装完后你可以用下面的命令确认本机 QEMU 是否认识龙架构qemu-system-loongarch64 --version如果能正常输出版本号说明 QEMU 可执行文件已就绪。4.2 获取系统镜像这一步是整个流程中最容易卡住的地方因为不同发行版提供的龙架构镜像格式、启动参数和默认配置都不完全一样。稳妥的做法是去你熟悉的 Linux 发行版官网查找是否有 LoongArch64 架构的系统镜像。优先选择官方提供的 QEMU 镜像或安装镜像。关注镜像说明中的启动参数和登录账号。这里不列出单一固定下载地址因为镜像下载链接变化较快而且不同镜像需要的启动命令确实存在差异。4.3 启动 QEMU 虚拟机拿到镜像后可以用类似下面的命令启动。这个命令是一个通用模板实际参数需要根据镜像说明调整qemu-system-loongarch64 \ -m 4G \ -smp 4 \ -machine virt \ -cpu LoongArch-virt \ -drive fileloongarch64.qcow2,formatqcow2,ifvirtio \ -netdev user,idnet0 \ -device virtio-net-pci,netdevnet0 \ -display default参数含义如下-m 4G给虚拟机分配 4GB 内存。-smp 4分配 4 个虚拟 CPU。-machine virt使用 QEMU 为龙架构提供的 virt 虚拟机器。不同版本的 QEMU 支持的 machine 名称可能不同如果提示找不到可以执行qemu-system-loongarch64 -machine help查看当前版本支持的列表。-cpu LoongArch-virt指定虚拟 CPU 型号。-drive fileloongarch64.qcow2,formatqcow2,ifvirtio挂载系统磁盘镜像。qcow2是 QEMU 常用的镜像格式不解包、占用空间小、支持快照。-netdev user,idnet0和-device virtio-net-pci,netdevnet0为用户模式网络连接创建虚拟网卡这样虚拟机内部可以访问外网。-display default如果是在有图形界面的环境会弹出虚拟机窗口在纯服务器环境可以改成-nographic使用串口控制台。4.4 验证系统是否启动成功系统启动并登录后第一步应该执行uname -m如果一切正常输出结果是loongarch64看到这个输出说明你已经在 LoongArch 指令集环境下运行命令了。接下来可以继续验证 CPU 信息cat /proc/cpuinfo | head -n 20这里会显示当前虚拟 CPU 的型号、feature 等信息能帮助你确认内核是否以龙架构模式启动。4.5 常见启动问题如果你执行启动命令后黑屏或报错优先检查三点QEMU 版本是否支持龙架构。较老版本的 QEMU 可能没有qemu-system-loongarch64。-machine和-cpu参数是否匹配镜像要求。不同镜像对虚拟硬件的要求不同。磁盘镜像路径是否正确以及当前用户是否有读取权限。QEMU 跑通的意义不只是“装了个系统”而是给你一个安全、可快照、可随时销毁的实验环境。后续做内核实验、软件交叉编译测试、系统级调试都可以在这个环境里先跑一遍。5. 容器与多架构构建loong64 的工程化实践在真实工程中很多人接触 LoongArch 不是因为买了龙芯电脑而是因为要在 CI 流水线里构建多架构镜像或者在容器环境里验证自己的软件能否在 loong64 上运行。5.1 认识多架构镜像容器镜像可以支持多个 CPU 架构。Docker 的 manifest list 机制允许同一个镜像名对应多个平台的镜像Docker 会根据运行环境的 CPU 架构自动拉取对应版本。龙架构在 Docker 生态中的平台标识通常是linux/loong64这个标识可以在需要手动指定平台时使用。例如查看某个镜像是否提供了龙架构版本docker buildx imagetools inspect --raw 镜像名:标签不过这个命令输出的原始 manifest 内容对新手不太友好。更直观的做法是直接尝试以龙架构平台拉取镜像看是否报错。5.2 使用 buildx 构建 loong64 镜像假设你有一个简单的 C 程序想在龙架构上以容器方式运行。这里提供一个不需要依赖任何基础镜像的简化版 Dockerfile# Dockerfile FROM scratch COPY hello-loongarch64 /hello ENTRYPOINT [/hello]这个镜像只包含一个静态编译的 LoongArch 可执行文件。FROM scratch表示空镜像没有任何系统库因此hello-loongarch64必须是静态编译的。构建命令docker buildx build --platform linux/loong64 -t example/hello:loong64 .这里的关键是--platform linux/loong64它告诉 buildx 我要构建面向龙架构的镜像。如果你的 Docker 环境没有启用 buildx可以先用docker buildx ls查看。构建完成后如果想在非龙架构机器上直接运行这个镜像通常会遇到exec format error因为 CPU 无法执行异构指令。这时需要借助 QEMU 的用户态模拟来运行或者把镜像推到支持龙架构的服务器上运行。5.3 工程中的注意事项在实际项目中多架构构建有一个经常被忽略的坑不是所有基础镜像都提供 loong64 版本。很多存量镜像只有 amd64 和 arm64 版本这会直接导致构建失败。因此在选择基础镜像时需要提前确认这个官方镜像是否发布 loong64 / loongarch64 变体如果还没有能否用FROM scratch或自建基础镜像解决需要用到哪些系统库龙架构的软件源里是否都有对应版本容器化的优势在于它把“系统环境”固化成构建产物一旦适配跑通就能批量分发。这也是龙架构生态建设中最值得投入的方向之一。6. 源码适配与交叉编译基础如果你手头有一个开源项目想要支持龙架构核心工作往往集中在编译环节。这里需要理解“交叉编译”和“原生编译”的区别。6.1 什么是交叉编译交叉编译是在一台机器上编译出能在另一种架构上运行的程序。比如你在 x86 的电脑上编译出一个 LoongArch 的可执行文件。对比一下原生编译在龙架构机器上编译龙架构程序产物直接在本机运行。交叉编译在非龙架构机器上编译龙架构程序产物需要拷贝到龙架构机器或模拟环境中运行。交叉编译的优势是可以复用你现有的 CI 机器和开发环境痛点在于需要维护一套交叉编译工具链并且一些构建脚本会默认在当前平台编译本地工具导致交叉编译经常失败。6.2 从源码到 loong64 可执行文件这里以一个最简单的 C 程序为例。我们先写一个hello.c#include stdio.h int main(void) { printf(Hello LoongArch!\n); return 0; }在 Debian/Ubuntu 系列发行版上可以通过包管理器搜索龙架构相关的交叉编译工具链apt search loongarch64搜索到对应工具链包后安装。安装完成后交叉编译命令类似loongarch64-linux-gnu-gcc -static -o hello-loongarch64 hello.c然后查看生成文件的架构信息file hello-loongarch64正常情况下输出中会包含类似LoongArch 64-bit的描述hello-loongarch64: ELF 64-bit LSB executable, LoongArch 64-bit, ...如果在自己的机器上无法运行这个文件可以把它拷贝到 QEMU 虚拟机或龙架构服务器上运行。静态编译的好处就在这里它不依赖目标系统上的动态库拷过去直接就能跑。6.3 构建脚本与配置的适配思路对于稍微复杂一点的项目直接改编译命令往往不够还需要处理构建系统配置。以 CMake 为例常见思路是编写一个龙架构工具链文件# loongarch64-toolchain.cmake set(CMAKE_SYSTEM_NAME Linux) set(CMAKE_SYSTEM_PROCESSOR loongarch64) set(CMAKE_C_COMPILER loongarch64-linux-gnu-gcc) set(CMAKE_CXX_COMPILER loongarch64-linux-gnu-g) set(CMAKE_FIND_ROOT_PATH /usr/loongarch64-linux-gnu) set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)使用时通过-DCMAKE_TOOLCHAIN_FILE指定cmake -DCMAKE_TOOLCHAIN_FILEloongarch64-toolchain.cmake .. make这个文件的核心是告诉 CMake目标系统是 Linux loongarch64编译器用交叉编译器查找库和头文件时只去交叉编译根目录找不要误用到本机 x86 的库。真正的适配难点也在这里很多大型项目会有arch相关的内联汇编、CPU feature 检测、优化选项需要逐个处理。这个过程没有捷径但一旦沉淀下来就是非常宝贵的生态资产。7. 常见问题与排查思路在龙架构环境的搭建和适配过程中有几个问题出现频率非常高。这里整理成一张排查表方便快速定位。问题现象可能原因排查方式解决方案QEMU 启动黑屏或无输出镜像架构与 QEMU 配置不匹配查看 QEMU 日志确认 machine/cpu 参数执行qemu-system-loongarch64 -machine help查看可用配置按镜像说明调整uname -m输出不是loongarch64启动的内核或系统版本不对在虚拟机内执行cat /proc/cpuinfo确认使用的是龙架构内核镜像及配套根文件系统Docker 运行报exec format error镜像架构与当前平台不匹配执行docker image inspect 镜像名查看 Architecture 字段使用--platform linux/loong64拉取或在龙架构机器上运行交叉编译产物在目标机上段错误动态链接库缺失或版本不匹配在目标机执行ldd ./程序改用-static静态编译或在目标机安装对应动态库CMake 找到本机 x86 库工具链文件未正确设置查找路径查看 CMake 输出的库路径检查CMAKE_FIND_ROOT_PATH确保库查找范围被限制源码中检测不到龙架构构建脚本缺少 LoongArch 平台分支搜索源码中的x86_64、aarch64等平台判断逻辑在对应判断逻辑中补充loongarch64分支二进制翻译运行 x86 应用性能低翻译执行本身就存在开销对比原生版本与翻译版本耗时优先寻找或打包该软件的原生龙架构版本遇到问题时的排查顺序建议永远是“先确认架构再看日志最后怀疑逻辑错误”。架构不匹配是最常见、最容易被忽略的起点。8. 从体验到贡献给开发者的实践建议如果你已经跑通了 QEMU 或容器环境下一步的关键是“别停留在体验层”。这里给出几条可执行的路径按照难度从低到高排列第一把你的常用工具链在龙架构环境里完整跑一遍。不需要选复杂项目就从 Python、Node.js、GCC 这些最基础的开始记录哪些能跑、哪些缺少依赖、哪些有报错。这些记录本身就是价值。第二挑一个你熟悉的小项目做适配测试。找那种依赖不太多、构建逻辑简单的工具库或命令行程序试着在龙架构环境里源码编译。遇到报错就修修的过程就是你理解项目构建逻辑的过程。第三关注双周会的技术议题带着问题参与。如果你已经在某个环节遇到具体障碍可以把问题整理成清晰的描述在社区渠道提出。技术会议最有价值的参与方式不是当听众而是提有效的技术问题。第四把适配经验沉淀为补丁和文档。开源软件适配龙架构最终要走到上游社区。你可以提交 PR、提交 bug report、补充构建文档。这些动作看起来不大但正是生态建设最稀缺的“最后一公里”。要注意的是龙架构生态处于上升期意味着边界在快速变化。半年前不可用的软件现在可能已经有原生版本上一季度的构建方法下个季度可能有更优解。保持持续跟进比一次性搞懂更重要。9. 总结从龙架构双周会第 42 期这个坐标点往回看LoongArch 已经走过了指令集定义、基础工具链适配、操作系统接入这几个关键阶段当前最值得关注的是应用层长尾软件和工程化基础设施的完善速度。对开发者来说现在入局的门槛并不高没有硬件用 QEMU 和 Docker 同样可以完成大量预研和适配工作需要的不是特别高深的技术而是耐心排查构建问题的工程能力。以后再有人问“龙架构能用了吗”更准确的回答方式是先问清楚他要在什么场景用——做服务器、做桌面、跑容器、还是做嵌入式。不同场景的生态成熟度差异很大。这也是双周会这类社区机制能持续存在的价值所在它让这些问题有地方被持续讨论并且让每个参与者的经验能沉淀下来成为整个生态的公共资产。
