RustDesk 源码构建实践：依赖准备、Linux 原生编译与 Docker 构建全流程

本篇基于 RustDesk 仓库的丹麦语版 README（docs/README-DA.md），完整梳理从源码构建 RustDesk 桌面版的全套流程：Sciter 动态库与 vcpkg 媒体依赖的准备方法、Ubuntu/Fedora/Arch 三大发行版的原生编译步骤，以及基于镜像缓存的 Docker 构建方式。读完后你可以独立完成 RustDesk 的调试构建、发行版适配构建与容器化构建，并能对照仓库源码理解每个构建步骤背后的依赖关系。

一、RustDesk 概览：自托管远程桌面与 GUI 双轨制

RustDesk 是一款用 Rust 编写的远程桌面软件，定位为可自托管的 TeamViewer 替代品。原文档的核心表述是：开箱即用、无需配置，数据完全由用户自己掌控；在 rendezvous/relay（会合/中继）服务上有三种选择——直接使用官方服务器、自建服务器，或者自行编写会合/中继服务器。贡献者指南见 docs/CONTRIBUTING.md。

从源码结构看，RustDesk 的桌面端存在两套 GUI 实现：

• Sciter GUI：基于 Sciter 引擎，对应 src/ui 目录下的 .tis/.html/.css 界面文件；
• Flutter GUI：对应独立的 flutter 目录，含 Android/iOS/macOS/Windows/Linux 各平台工程。

本文档的构建指南仅针对 Sciter 版本，这也是下文所有依赖与运行步骤的适用前提。

二、依赖准备：Sciter 动态库与 vcpkg 媒体依赖

2.1 Sciter 动态库需要手动下载

桌面版本使用 Sciter 或 Flutter 做 GUI，构建指南仅覆盖 Sciter 路线。原文档明确要求"请自行获取 Sciter 动态库"，按平台分别是三个产物：

平台	动态库文件名
Windows	sciter.dll
Linux	libsciter-gtk.so
macOS	libsciter.dylib

这三个文件来自 Sciter 官方 SDK 的发布目录（bin.win/x64、bin.lnx/x64、bin.osx），下载后需放到可执行文件的运行时搜索路径——Linux 构建流程中会将其放入 target/debug，详见第四节。

2.2 vcpkg 媒体依赖：libvpx、libyuv、opus、aom

文档给出的"原始步骤"（Rå trin til at bygge）是：

1. 准备好 Rust 开发环境与 C++ 构建环境；
2. 安装 vcpkg 并正确设置环境变量 VCPKG_ROOT；
3. 安装依赖：
   • Windows：vcpkg install libvpx:x64-windows-static libyuv:x64-windows-static opus:x64-windows-static aom:x64-windows-static
   • Linux/MacOS：vcpkg install libvpx libyuv opus aom
4. 执行 cargo run。

这四组依赖正是远程桌面最核心的媒体能力栈，仓库配置可以印证这一点。根目录 vcpkg.json 声明了 libvpx、libyuv、opus、aom 四组依赖（均含 host 端构建依赖），并按平台条件附加了 mfx-dispatch（Intel 硬解）和 ffmpeg（启用 amf/nvcodec/qsv 等硬件编解码 feature）；同时通过 overlay-ports 指向本地补丁目录 res/vcpkg，其中为 aom、ffmpeg、libvpx、libyuv、opus 等 port 提供了自定义 portfile 与修复补丁，vcpkg-configuration.baseline 固定为 9e593bb18ea69cc5095e012465dcd675a822ed0d 以保证可重复构建。

再从 Cargo.toml 看 Rust 侧的对应关系：scrap（屏幕采集，启用 wayland feature）与 hbb_common 以本地路径依赖引入，magnum-opus、kcp-sys、cpal（音频采集，Linux 上按 discussions 结论被排除）等以 git 依赖引入——vcpkg 提供的 C 库与这些 Rust crate 共同构成了"采集 → 编码（libvpx/aom）→ 音频（opus）→ 传输（KCP/TCP）"的完整链路。

三、最简构建路径

若系统依赖已就绪，文档给出的最小步骤就是上面第二节末尾的 cargo run 一条命令：准备 Rust 与 C++ 环境、安装并设置 VCPKG_ROOT、装好四组 vcpkg 依赖后即可直接运行。这是适合快速验证环境的"冒烟"路径；下面两节分别给出 Linux 原生构建与 Docker 构建的完整细节。

四、Linux 原生构建完整流程

4.1 各发行版系统依赖

Ubuntu 18 / Debian 10：

sudo apt install -y g++ gcc git curl wget nasm yasm libgtk-3-dev clang libxcb-randr0-dev libxdo-dev libxfixes-dev libxcb-shape0-dev libxcb-xfixes0-dev libasound2-dev libpulse-dev cmake

Fedora 28 / CentOS 8：

sudo yum -y install gcc-c++ git curl wget nasm yasm gcc gtk3-devel clang libxcb-devel libxdo-devel libXfixes-devel pulseaudio-libs-devel cmake alsa-lib-devel

Arch / Manjaro：

sudo pacman -Syu --needed unzip git cmake gcc curl wget yasm nasm zip make pkg-config clang gtk3 xdotool libxcb libxfixes alsa-lib pipewire

从包列表可以读出各依赖的用途：libgtk-3-dev 对应 Sciter 的 GTK 后端（libsciter-gtk.so）；libxcb-*-dev 系列是 X11 屏幕采集所需的 XCB 扩展；libxdo-dev/xdotool 对应键鼠输入注入（libs/enigo 的 Linux 实现依赖 libxdo）；libasound2-dev/libpulse-dev 是 ALSA 与 PulseAudio 音频栈；nasm/yasm 则用于 libvpx 等汇编代码的编译。

4.2 安装 vcpkg 并固定版本

git clone https://github.com/microsoft/vcpkg
cd vcpkg
git checkout 2023.04.15
cd ..
vcpkg/bootstrap-vcpkg.sh
export VCPKG_ROOT=$HOME/vcpkg
vcpkg/vcpkg install libvpx libyuv opus aom

注意 git checkout 2023.04.15 这一步：vcpkg 是滚动仓库，固定到特定 release tag 才能保证依赖构建的可复现性。仓库的 Dockerfile 中也执行了相同的固定操作（git clone --branch 2023.04.15 --depth=1），两条构建路线在此保持一致。

4.3 Fedora 的 libvpx 修正（-fPIC）

文档为 Fedora 单独提供了一段手动修正流程：

cd vcpkg/buildtrees/libvpx/src
cd *
./configure
sed -i 's/CFLAGS+=-I/CFLAGS+=-fPIC -I/g' Makefile
sed -i 's/CXXFLAGS+=-I/CXXFLAGS+=-fPIC -I/g' Makefile
make
cp libvpx.a $HOME/vcpkg/installed/x64-linux/lib/
cd

原理是 Fedora 的 GCC 对链接进共享库/可执行文件的静态目标代码要求强制 -fPIC，而 vcpkg 构建 libvpx 时生成的 Makefile 默认未加该标志，链接阶段会报 relocation 错误。这段命令进入 vcpkg 已展开的 libvpx 源码树，用 sed 给 CFLAGS/CXXFLAGS 注入 -fPIC 后手动重编，再把 libvpx.a 拷回安装目录替换。这是典型的"发行版工具链差异 vs 静态依赖"问题，在 Arch/Ubuntu 上通常不会触发。

4.4 编译与运行

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
source $HOME/.cargo/env
git clone https://github.com/rustdesk/rustdesk
cd rustdesk
mkdir -p target/debug
wget https://raw.githubusercontent.com/c-smile/sciter-sdk/master/bin.lnx/x64/libsciter-gtk.so
mv libsciter-gtk.so target/debug
cargo run

几个关键细节：

• mkdir -p target/debug + 把 libsciter-gtk.so 移入其中：RustDesk 运行时从可执行文件所在目录加载 Sciter 动态库，因此动态库必须与 target/debug/rustdesk 同目录；
• 仓库的 libs/hbb_common 是一个 git 子模块（见 .gitmodules，指向 rustdesk 组织下的 hbb_common 仓库），首次 clone 建议带上子模块参数，否则本地路径依赖会指向空目录导致编译失败；
• cargo run 默认产出 debug 构建，适合开发调试。

五、Docker 构建流程

Docker 路线把整套 Linux 构建环境固化进镜像，避免在宿主机折腾依赖。仓库根目录的 Dockerfile 基于 debian:bullseye-slim，安装的系统包与 4.1 节 Ubuntu 包列表同源（另加 libssl-dev、gstreamer、ninja-build 等），并同样固定 vcpkg 到 2023.04.15、安装 libvpx libyuv opus aom，最后预下载 libsciter-gtk.so 并安装 Rust 工具链。

第一步：构建构建器镜像

git clone https://github.com/rustdesk/rustdesk
cd rustdesk
docker build -t "rustdesk-builder" .

第二步：挂载仓库执行构建

docker run --rm -it -v $PWD:/home/user/rustdesk -v rustdesk-git-cache:/home/user/.cargo/git -v rustdesk-registry-cache:/home/user/.cargo/registry -e PUID="$(id -u)" -e PGID="$(id -g)" rustdesk-builder

这条命令的每个挂载与环境变量都有明确目的：

• -v $PWD:/home/user/rustdesk：把宿主机仓库目录映射进容器，构建产物直接落回宿主机；
• -v rustdesk-git-cache:... 与 -v rustdesk-registry-cache:...：将 Cargo 的 git 依赖与 crate registry 缓存持久化到命名卷——文档特别提示首次构建较慢，依赖缓存之后会显著加快；
• -e PUID/-e PGID：传入宿主机当前用户的 uid/gid，避免容器内构建产生的 target/ 文件属主与宿主用户不一致。

可选参数与产物位置：文档说明可以在命令末尾追加可选参数（<VALGFRI-ARGS> 位置）来透传给构建命令，例如追加大写 --release 构建优化版本。构建完成后：

target/debug/rustdesk

或发布版：

target/release/rustdesk

这些源码可以直接印证可选参数的处理逻辑：entrypoint.sh 是一个参数解析脚本，循环识别 --release（置位 release 标志）与 --target（动态 rustup target add），其余参数原样透传；它还会把预下载的 libsciter-gtk.so 复制到 target/debug 或 target/release，最后以 VCPKG_ROOT=/vcpkg cargo build --locked $argv 收尾——--locked 保证严格按 Cargo.lock 解析依赖。

文档同时给出两条重要限制，务必注意：

1. 必须从仓库根目录运行可执行文件，否则程序可能找不到所需资源；
2. cargo install、cargo run 等子命令不受此容器化方式支持——它们会在容器内部执行/安装，而不是落到宿主机上。

六、构建产物对应的源码结构（Filstruktur）

原文档的"Filstruktur"一节列出了八个核心模块，结合当前仓库逐一核实如下：

模块	文档描述	仓库现状
libs/hbb_common	视频编解码、配置、tcp/udp 封装、protobuf、文件传输的 fs 功能及其他辅助	确认为 git 子模块（见 .gitmodules）
libs/scrap	屏幕采集	libs/scrap/src/common 下按平台组织：dxgi.rs/quartz（Windows/macOS）、x11/wayland/linux.rs（Linux），另有 vpx.rs、aom.rs、hwcodec.rs 等编解码后端，与 vcpkg 依赖一一对应
libs/enigo	平台相关键鼠控制	含 linux/nix_impl.rs、linux/xdo.rs、macos/macos_impl.rs、win/win_impl.rs 等平台实现
src/ui	GUI	Sciter 界面文件（cm.tis、remote.tis、*.css 等）
src/server	音频/剪贴板/输入/视频服务与网络连接	可看到 audio_service.rs、clipboard_service.rs、input_service.rs、display_service.rs、video_service.rs 等文件，与文档描述逐一对应
src/client.rs	发起 peer 连接	已确认存在
src/rendezvous_mediator.rs	与会合/中继服务器通信，等待 TCP 打洞直连或中继连接	已确认存在
src/platform	文档标注为"Flutter Web 客户端的 JavaScript"	从当前源码结构看，该目录实际存放的是原生平台代码（macos.mm、windows.cc、linux.rs、privileges_scripts 等），而 Flutter Web 客户端的 JS/桥接代码位于 flutter/lib/web 目录

最后一行体现了文档随项目演进的滞后：建议以当前目录实际内容为准，把 src/platform 理解为"原生平台适配层"。

七、构建前自检清单

综合全文，开始构建 RustDesk 之前可按以下清单核对：

1. 环境：Rust 工具链（rustup）与 C++ 编译器均已就绪；
2. vcpkg：VCPKG_ROOT 已正确导出，且已执行 vcpkg install libvpx libyuv opus aom（Windows 使用 x64-windows-static triplet）；建议 vcpkg 固定到 2023.04.15 以对齐 Dockerfile；
3. Sciter：对应平台的动态库（sciter.dll / libsciter-gtk.so / libsciter.dylib）已下载，Linux 下已放入 target/debug；
4. 子模块：libs/hbb_common 子模块已拉取（.gitmodules）；
5. 发行版差异：Fedora 用户留意 libvpx 的 -fPIC 修正步骤；
6. Docker 路线：命名卷缓存已创建（首次构建较慢属正常现象），构建命令末尾可追加 --release 等可选参数，但 cargo install/cargo run 子命令不可用于容器方式。

原文档末尾还附有 4 张官方界面截图（登录/连接/文件传输等场景），本文依图片使用规范未予嵌入，可查阅 docs/README-DA.md 原文获取。