RustDesk 从源码构建完全指南：vcpkg 依赖、Linux 各发行版命令、Docker 构建与仓库模块结构

本文以 RustDesk 仓库的本地化文档 docs/README-GR.md（官方 README 的希腊语版本）为主线，完整整理其“构建前置条件、通用构建步骤、Linux 各发行版依赖安装、vcpkg 安装、Docker 构建、仓库目录结构”六大主题，并结合当前仓库的实际源码与配置文件（Cargo.toml、Dockerfile、entrypoint.sh、vcpkg.json 等）逐节验证、扩充，帮助你从零在本地或容器环境中把 RustDesk 编译运行起来，同时理解各构建步骤背后对应的代码模块与依赖机制。

项目定位与文档背景

RustDesk 是一款使用 Rust 编写的开源远程桌面应用，面向自托管场景，是 TeamViewer 的开源替代方案。其核心特点是：安装后即可直接使用（开箱即用），使用方既可以依赖默认的公共 rendezvous/中继服务器，也可以部署自己的服务器，把连接数据完全掌握在自己手中。

docs/README-GR.md 是英文主文档 README.md 的希腊语翻译版，除语言差异外，其技术内容与主文档保持一致：涵盖构建前置条件、跨平台通用构建步骤、Linux 各发行版的依赖安装命令、Docker 构建方式以及仓库目录结构说明。本文以该文档为骨架，所有命令均按原文档继承，并在仓库源码中逐一印证其依据。

构建前置条件（Pre-requisites）

原文档在“Προαπαιτούμενα για build（构建前置条件）”一节指出，桌面端版本有两种 UI 技术路线：Sciter 或 Flutter，文档中的构建步骤仅针对 Sciter 路线。构建者需要自行下载 Sciter 动态库，原文档给出三个平台的对应文件名：

平台	需要下载的动态库
Windows	sciter.dll（x64）
Linux	libsciter-gtk.so（x64）
MacOS	libsciter.dylib

这一点在当前仓库中可以得到印证：

• Cargo.toml 在非移动端目标下依赖 sciter-rs，并在 flutter feature 开启时改用 flutter_rust_bridge，对应文档中“Sciter 与 Flutter 两条 UI 路线”的说法；
• Dockerfile 第 53 行在镜像中预下载了 libsciter-gtk.so 到 /home/user，与原文档“Linux 需要 libsciter-gtk.so”的要求完全一致；
• entrypoint.sh 在每次构建时会把该动态库拷贝到 target/debug 或 target/release 目录（test -f target/debug/libsciter-gtk.so || cp ...），这正是文档中“下载后 mv 到 target/debug”步骤在容器化场景下的自动化版本。

此外，原文档的“Γενικά βήματα（通用构建步骤）”要求：

1. 准备 Rust 与 C++ 两套开发环境；
2. 安装 vcpkg 并正确设置环境变量 VCPKG_ROOT；
3. 按平台安装 C 依赖：
   • 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。

“Rust + C++ 双环境”的要求在当前仓库中同样有据可查：build.rs 会在构建期用 cc crate 编译 src/platform/windows.cc、src/platform/windows_delete_test_cert.cc（Windows）或 src/platform/macos.mm（macOS，-std=c++17），即原生代码是构建链的一部分，缺少 C++ 工具链会直接构建失败。而 libvpx/libyuv/opus/aom 这四个依赖正是视频编码（VP8/VP9、AV1）与音频编码（Opus）链路，它们在 vcpkg.json 中同时声明了 host: true（交叉编译工具链）与 host: false（目标端运行时）两份依赖，这也解释了为何原文档要求“正确设置 VCPKG_ROOT”——vcpkg 需要在构建期同时为主机与目标架构解析出这两套库。

Linux 构建详解（按发行版）

原文档“Πως να το κάνετε build στο Linux（如何在 Linux 上构建）”给出了四个发行版的依赖安装命令，全部完整保留如下。

Ubuntu 18 / Debian 10

sudo apt install -y zip 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 make \
        libclang-dev ninja-build libgstreamer1.0-dev libgstreamer-plugins-base1.0-dev

openSUSE Tumbleweed

sudo zypper install gcc-c++ git curl wget nasm yasm gcc gtk3-devel clang libxcb-devel libXfixes-devel cmake alsa-lib-devel gstreamer-devel gstreamer-plugins-base-devel xdotool-devel

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

这些依赖与官方 Dockerfile 中的 apt install 清单高度对应（g++、gcc、git、curl、nasm、yasm、libgtk-3-dev、clang、libxcb-*、libxdo-dev、libxfixes-dev、libasound2-dev、libpulse-dev、libgstreamer1.0-dev、libgstreamer-plugins-base1.0-dev、ninja-build 等），可以推断 CI 与本地构建共享同一套依赖基线。其中：

• nasm/yasm 是 x264/VPX 等汇编优化编译所必需的汇编器；
• libxcb-*、libxdo-dev、libxfixes-dev 服务于 X11 屏幕采集与输入注入，对应 libs/scrap/src/x11 与 libs/enigo/src/linux 下的实现；
• libasound2-dev/libpulse-dev/pipewire 服务于音频采集，对应 src/server/audio_service.rs；
• GStreamer 相关包用于 Linux 端的媒体管线支持。

安装 vcpkg

原文档指定了 vcpkg 的版本基线（2023.04.15），这一步在 Dockerfile 第 42–44 行中被原样执行（git clone --branch 2023.04.15 + bootstrap-vcpkg.sh + install libvpx libyuv opus aom），说明该版本基线是官方构建链的一部分：

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

补充说明：当前仓库根目录的 vcpkg.json 还配置了 overlay-ports: ./res/vcpkg 与 overlay-triplets: ./res/vcpkg-triplets，即仓库内 res/vcpkg 下自带 aom、ffmpeg、libvpx、libyuv、mfx-dispatch、opus 的定制端口与补丁（例如 res/vcpkg/aom/portfile.cmake、res/vcpkg/ffmpeg/portfile.cmake），并声明了 ffmpeg、libjpeg-turbo、mfx-dispatch、libsodium 等更多依赖及其平台条件（如硬件编解码的 amf/nvcodec/qsv feature 仅在静态链接的 Windows/Linux x86 平台启用）。手动 vcpkg install 四件套是最小路径，而完整特性集（如 hwcodec）则依赖仓库内 overlay 端口体系，Cargo.toml 中的 hwcodec、vram、mediacodec、drm 等 feature 开关就是与之对应的编译入口。

Fedora 下 libvpx 的 -fPIC 修复

原文档专门给出了 Fedora 上 libvpx 静态库缺 -fPIC 导致链接失败的修复流程，完整继承如下：

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

其原理是：RustDesk 将 libvpx.a 静态链接进最终可执行文件（含 PIE 目标），Fedora 的 CFLAGS 默认未给 C 编译加 -fPIC，导致静态库中的对象不是位置无关代码，链接时会被拒。通过 sed 在 Makefile 的 CFLAGS/CXXFLAGS 上补 -fPIC 后重新编译，再把 libvpx.a 覆盖回 vcpkg 的 installed/x64-linux/lib/ 即可。仓库内 res/vcpkg/libvpx 目录中也维护了针对 libvpx 的构建补丁（如 0004-remove-library-suffixes.patch），说明 libvpx 的构建细节是项目持续维护的构建痛点。

完整构建流程（Linux 手动路径）

原文档给出的端到端构建命令序列如下（克隆地址以本仓库镜像为准）：

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
source $HOME/.cargo/env
git clone https://gitcode.com/GitHub_Trending/ru/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
VCPKG_ROOT=$HOME/vcpkg cargo run

关键约束有两条：

1. libsciter-gtk.so 必须放在 target/debug 下（debug 构建时运行时依赖它），entrypoint.sh 在 Docker 场景中也执行了同样的拷贝逻辑；
2. 必须导出 VCPKG_ROOT，让构建脚本能找到前面安装的 C 依赖。

从 Cargo.toml 看，default-run = "rustdesk" 且 rust-version = "1.75"，当前仓库版本为 1.4.9，因此 cargo run 等价于运行 rustdesk 可执行文件；src/main.rs 显示非 Flutter 构建入口会先经 core_main 解析启动参数（如 service、install 等子命令），再进入 ui::start 启动界面，这与 src/ui 中 Sciter 的 html/tis/css 模板文件结构相互印证。

Docker 构建详解

原文档“Πως να κάνετε build στο Docker”给出的命令如下：

git clone https://gitcode.com/GitHub_Trending/ru/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

Docker 构建链在仓库中的实现

• 镜像定义：Dockerfile 基于 debian:bullseye-slim，依次安装前文 Ubuntu 一节同款 apt 依赖、从源码编译安装 CMake 3.30.6、检出 vcpkg 2023.04.15 并 install libvpx libyuv opus aom，创建无 root 权限的 user 用户，预下载 libsciter-gtk.so，最后通过 rustup 安装 Rust 工具链；
• 入口脚本：entrypoint.sh 解析容器参数，支持 --release（自动切换到 release 目录并把 sciter 动态库拷到 target/release）与 --target <triple>（动态添加 rustup 交叉编译目标），最终执行 VCPKG_ROOT=/vcpkg cargo build --locked $argv；
• 卷缓存机制：命令中的 rustdesk-git-cache 与 rustdesk-registry-cache 两个命名卷缓存 ~/.cargo/git 与 ~/.cargo/registry，正如原文档所述“首次构建较慢（缓存依赖），后续构建更快”。

产物位置与限制

按原文档说明：

• debug 产物：target/debug/rustdesk
• release 产物：追加 --release 参数后为 target/release/rustdesk
• 必须在仓库根目录执行，否则应用可能找不到所需资源；
• install、run 等子命令不受该 Docker 方式支持——因为它们会在容器内而非宿主机上安装/运行程序。

这一限制与 entrypoint.sh 的实现相符：脚本始终只调用 cargo build，从未处理 install/run 语义。

仓库目录结构（Δομή φακέλων）

原文档的“Δομή φακέλων（文件夹结构）”一节列出了核心模块及其职责，全部继承并转换为仓库根目录相对路径如下，同时补充源码级证据：

模块	职责（原文档）	仓库内印证
libs/hbb_common	视频编解码封装、配置、tcp/udp 封装、protobuf、文件传输的 fs 函数及其他工具函数	Cargo.toml 依赖 hbb_common = { path = "libs/hbb_common" }，src/client.rs 通过它引入 config、message_proto、rendezvous_proto、kcp 等
libs/scrap	屏幕采集	libs/scrap/src 下有 x11、wayland、dxgi、quartz、android、common 等按平台拆分的采集后端，common 内还包含 aom.rs、vpx.rs、hwcodec.rs、camera.rs 等编解码与采集实现
libs/enigo	平台相关的键盘/鼠标控制	libs/enigo/src 按 linux（含 xdo 与 nix 实现）、macos、win 分包
src/ui	GUI	Sciter 模板体系：index.html/tis/css、remote.*、file_transfer.*、chatbox.html 等
src/server	音频/剪贴板/输入/视频服务及网络连接	audio_service.rs、clipboard_service.rs、input_service.rs、video_service.rs、connection.rs、service.rs（服务订阅框架 Service trait）等
src/client.rs	发起点对点连接	约 4300 行的客户端核心，包含输入发送（MOUSE_TYPE_DOWN 等）、KcpStream、secure_tcp、音频解码（magnum_opus）等
src/rendezvous_mediator.rs	与 rustdesk-server 通信，等待远程直连（TCP 打洞）或中继连接	源码中处理 RegisterPeerResponse、PunchHole、RequestRelay、ConfigureUpdate 等 rendezvous 消息分支，并有 get_relay_server 回退逻辑，与文档描述一一对应
src/platform	平台相关代码	windows.rs/.cc、macos.rs/.mm、linux.rs、gtk_sudo.rs、delegate.rs，配合 build.rs 的原生编译
flutter	移动端 Flutter 代码	lib/common、lib/desktop、lib/mobile、lib/models 等完整 Flutter 应用结构，各平台工程目录齐备

从源码结构看，客户端连接建立的主链是：src/client.rs 发起会话 → src/rendezvous_mediator.rs 向 rendezvous 服务器注册并接收打洞/中继指令 → 建立加密 TCP/KCP 通道；被控端则由 src/server 下的各服务（视频、音频、输入、剪贴板、打印机、终端等）通过 service.rs 中的 Service 订阅框架分发远端请求。文档中“等待远程直连（TCP hole punching）或中继连接”的描述与 PunchHole/RequestRelay 两个消息分支完全吻合。

适用前提与小结

• 本文所有构建步骤以 docs/README-GR.md（同 README.md）描述的 Sciter 桌面版构建链为准，当前仓库版本 1.4.9，要求 Rust ≥ 1.75（见 Cargo.toml 的 rust-version）；
• vcpkg 版本基线为 2023.04.15（Dockerfile 与原文档一致），Linux/MacOS 最小依赖集为 libvpx libyuv opus aom，Windows 需追加 x64-windows-static triplet 后缀；
• Linux 各发行版命令仅保证在文档列出的 Ubuntu 18/Debian 10、openSUSE Tumbleweed、Fedora 28/CentOS 8、Arch/Manjaro 环境上验证，其他发行版请对照 Dockerfile 的依赖清单自行映射；
• 移动端（Android/iOS）与 Flutter 桌面版走另一条构建链（见 flutter 目录及其 build_android.sh、ndk_*.sh 等脚本），不在本文档范围内。

掌握以上内容后，你可以按“安装系统依赖 → 固定版本 vcpkg → 安装 C 库 → 放置 sciter 动态库 → VCPKG_ROOT=... cargo run”的主线在本地构建 RustDesk，或直接用 docker build / docker run 复用官方构建镜像完成同样工作，并能对照 src、libs、flutter 三大模块理解每个构建依赖（X11/Wayland 采集、Opus/VPX 编解码、剪贴板与输入注入）在代码中的落点。