简介Telegram编译过程记录及问题解决方案集锦面向有一定C和Windows开发基础、尝试自行编译开源IM Telegram及Qt 5.3.1的开发者。文档基于VS2013环境梳理了环境准备、OpenSSL、LZMA、zlib、libexif等组件配置重点记录Qt 5.3.1静态编译步骤与半成品合并思路以及编译Telegram时“找不到openssl\bn.h”、C2059语法错误、QtMultimedia/QSoundEffect缺失、Qt5Widgets.lib缺失、libeay32MT.lib链接失败等典型问题的排查与解决办法。压缩包内仅含1个doc文件大小29KB内容精炼。已有569人浏览学习适合需要快速定位编译错误、节省排错时间的开发者参考。1. 编译 Telegram 前必须想清楚的三件事看到“Telegram编译以及问题解决(包含QT5.3.1编译)”这个标题你可能已经在电脑前折腾了一下午源码拉下来了依赖装了一堆结果 configure 一跑就报错或者 make 到一半被 undefined reference 劝退。我最早碰这个项目时也一样后来发现编译 Telegram 最大的坑不在 Telegram.js而在 Qt 版本和工具链之间的耦合关系。这里的 QT5.3.1 是很多老项目仍在用的固定版本今天编译它既要面对 gcc 新版本带来的 ABI 不兼容又要处理 qscintilla 下载与编译这类子模块的连带问题。这篇笔记适合两类人一是需要在离线或受限环境里自己构建 Telegram 的部署工程师二是想拿 Telegram 源码练习 Qt 静态编译和二次开发的学习者。读完你至少能跑通一个本地可执行文件并知道每个报错该去哪查。2. 搭建 Telegram 编译环境依赖、工具链与系统选择2.1 编译 Telegram 需要哪些依赖从基础库到专有组件Telegram 桌面版不是那种只靠apt install就能轻松编过的软件它依赖的库分三层基础系统库、Qt 模块层、Telegram 自己的子模块。先别急着装 Qt先把底层缺口补上。按我常做的方案在 Debian/Ubuntu 这一类系统上需要先准备好编译工具链和底层库包括build-essential、git、automake、libtool、zlib1g-dev、libssl-dev、libicu-dev、liblz4-dev、libxxhash-dev、libevent-dev以及libexif-dev。OpenSSL 和 ICU 这两个最容易出问题后面我会详细说为什么。Telegram 老版本源码里还有一层叫Telegram-Desktop/ThirdParty的子模块里面会用到qscintilla、libtgvoip、libyuv这些组件。其中qscintilla是要单独编译的而且它的编译依赖于 Qt 的 qmake所以如果你想让 Qt 和 Telegram 都从源码构建顺序必须是这样先编译 Qt 5.3.1再编译 qscintilla最后再编译 Telegram 本体。这看起来像编译原理里的依赖分析但实际比那个朴素得多——就是一层层往上垒每一步的安装路径都要让下一步能找到。我见过有人想省事用 apt 直接装系统自带的 Qt 5.15然后去编译老版本的 Telegram 源码结果一堆 API 调用直接作废。所以如果你想复现标题里的 QTS5.3.1 编译流程就别换 Qt 版本。系统上已经装了新版 Qt 也没关系把旧 Qt 安装到自定义前缀下用环境变量隔离即可。2.2 用脚本一键准备依赖我在 Debian/Ubuntu 上的做法下面这个脚本是我在 Ubuntu 20.04 上验证过的最小依赖集合注意它没装 Qt因为 Qt 我们要自己编。#!/bin/bash # 环境准备脚本编译 Telegram 所需基础依赖 set -e sudo apt update # 编译工具链与版本控制 sudo apt install -y build-essential git ccache automake libtool # 底层库 sudo apt install -y zlib1g-dev libssl-dev libicu-dev \ liblz4-dev libxxhash-dev libevent-dev libexif-dev # 可选如果你后续要处理裁剪后的图标 sudo apt install -y libgtk-3-dev libgdk-pixbuf2.0-dev这段脚本的关键点在于libssl-dev和libicu-dev必须安装。Telegram 的网络层用 OpenSSL 做加密文本处理用 ICU 做 Unicode 支持。缺少这两个库时Qt 的 configure 阶段不会报错但到 Telegram 本体链接阶段会出现cannot find -lssl或cannot find -licui18n这类错误那时候再补装就要重新跑一次 configure很浪费时间。liblz4-dev和libxxhash-dev是 Telegram 自带的压缩和哈希依赖如果系统没有编译libtgvoip时会很痛苦。另外建议手动关闭系统的 Qt 环境变量避免干扰。在.bashrc里加一句export QT_SELECTqt4 export QMAKESPEClinux-g这样在编译旧版 Qt 的时候configure 会去找正确的 qmake spec而不是误用系统自带的 Qt 5.15。2.3 为什么不建议用太新的系统Qt 版本与工具链的隐形约束很多人拿到标题里 “QT5.3.1编译” 就直接在最新的 Ubuntu 24.04 上开工然后一头撞在 gcc 版本上。Qt 5.3.1 是 2014 年发布的那时候主流编译器是 gcc 4.8而今天的 Ubuntu 24.04 默认 gcc 是 13。gcc 13 的 C11 ABI 与 5.3.1 时代存在大量不兼容典型表现是编译 Qt 源码时出现undefined reference to std::__cxx11::basic_string这类链错误。所以我的建议是首选 Ubuntu 20.04 或 Debian 10/11因为它们的 gcc 默认 9 或 10虽然也偏新但可以通过安装 gcc-8 或 gcc-7 来匹配老版本。如果你只能在最新系统上折腾那就要做好打补丁的准备了我后面专门有一节讲 Qt 5.3.1 与 gcc 新版的兼容性修复。另一个隐约束是 OpenSSL 版本。Ubuntu 20.04 自带的 OpenSSL 1.1.1Telegram 老源码编译时一般能认但 Ubuntu 22.04 以上变成了 OpenSSL 3.xQt 5.3.1 的qtnetwork模块读取配置的方式会有问题轻则警告重则让 TLS 初始化失败。如果你不是非要老版本现在 Telegram 官方源码其实已经移到了 CMake 体系用 Qt 6 或 Qt 5.15 都能编。但标题既然点名 QT5.3.1大概率是某个企业项目或旧设备指定了这套版本那我们就按着这个旧版本来。记住一句话版本是约束不是选择。3. QT5.3.1 编译旧版 Qt 在今天还能不能跑3.1 下载与解压版本、补丁与校验Qt 5.3.1 的源码包名是qt-everywhere-opensource-src-5.3.1.tar.xz大约 250MB 左右。解压后目录名会带版本号比如qt-everywhere-opensource-src-5.3.1。这一步没什么花样但我建议你下载后先做一件事校验 SHA1 或 SHA256。官方站点会给出校验值这能避免下到的不完整包导致 configure 阶段出现奇怪的语法错误。# 下载后解压 tar -xf qt-everywhere-opensource-src-5.3.1.tar.xz cd qt-everywhere-opensource-src-5.3.1 # 检查文件完整性替换为官方给出的真实哈希值 echo 填实际sha256值 qt-everywhere-opensource-src-5.3.1.tar.xz | sha256sum -c如果校验失败别忙着找补丁先重新下载。我遇到过解压后qmake生成就失败的情况最后发现是网络中断导致压缩包内容不完整。这个步骤虽然基础但在离线环境里往往是最容易翻车的一环。解压后建议立刻给整个目录设置清理变量export QT_BUILD_ROOT$PWD export INSTALL_PREFIX/opt/qt5.3.1这里的/opt/qt5.3.1是自定义安装路径好处是后续卸载只需要删目录不会污染系统 Qt。这也方便你在同一台机器上同时保留系统 Qt用PATH切换。3.2 configure 与 make参数详解和常见失败点Qt 5.3.1 的 configure 不是 CMake它的参数非常多但我们必须关注的只有几个核心项。下面是我常用的一个最小配置重点是为 Telegram 准备动态编译版本。cd $QT_BUILD_ROOT ./configure \ -prefix $INSTALL_PREFIX \ -opensource \ -confirm-license \ -release \ -shared \ -qt-zlib \ -qt-libpng \ -qt-libjpeg \ -qt-xcb \ -no-qml-debug \ -skip qtwebkit \ -skip qtlocation \ -skip qtconnectivity \ -skip qtmultimedia \ -nomake examples \ -nomake tests-prefix指定最终安装目录-opensource和-confirm-license是为了跳过交互问答-release去掉 Debug 符号节省磁盘空间-shared表示动态链接如果你打算静态编译 Telegram需要改为-static但静态编译时 Glibc 依赖比较麻烦我不建议新手上来就试。-qt-zlib、-qt-libpng、-qt-libjpeg是让 Qt 使用自己内置的三方库避免系统库版本不匹配。这对后面编译 qscintilla 有帮助因为 qscintilla 编译时会搜索 zlib 头文件。-skip qtwebkit等参数用来裁剪不必要的模块能大幅缩短编译时间。Telegram 老版本只需要qtbase、qtdeclarative、qtimageformats、qtwebchannel、qtsvg这几个模块其余都可以跳过。如果你因为缺少某个模块导致 Telegram 编译失败可以再回过头来只编译那个模块而不需要全部重编。Sk 参数在这里就是后悔药。configure 通过后会提示你运行make -jN。这里的 N 我一般取 CPU 核心数减一。8 核机器用-j716 核用-j15避免把系统内存吃满。make -j$(nproc --ignore1)Qt 5.3.1 全模块编译大约需要四十分钟到一小时如果只裁剪到基础模块二十分钟能搞定。编译过程中如果中断继续执行make即可它支持增量编译不用从头再来。但要注意不要在编译一半时去修改 configure 生成的 Makefile不然后续增量编译的行为可能不可预测。3.3 Qt 5.3.1 与 gcc 新版本的兼容性修复这是整个编译流程里最容易让新手崩溃的地方。如果您的系统 gcc 版本高于 7编译 Qt 5.3.1 大概率会遇到几个已知问题。我列两个最常见的第一个是qstandardpaths_linux.cpp编译失败报错信息通常带有double free or corruption或者std::allocator相关字样。这个问题的原因是老代码里局部变量被静态函数引用而新版 gcc 加强了生命周期检查。解决方式是在该文件开头添加一行#include functional并修改对应的变量为显式类型。不过具体改动因版本而异我通常直接跳过去看下一个。第二个是 gcc 7/8 导致的模板实例化错误出现在qtbase/src/corelib/io/qdatastream.cpp报错unspecialized template class。这个需要给qdatastream.h中的友元声明加上template前缀。如果你看到类似invalid use of incomplete type的报错多半是这个。修复步骤是cd qtbase/src/corelib/io # 编辑 qdatastream.h找到下面的行 # friend QDataStream operator(QDataStream , qfloat16 ); # 改为 # template friend QDataStream operator(QDataStream , qfloat16 );还有一个高频坑是qsqlite模块在编译时报cannot find -lpublic。这个错误看起来像找不到库实际是因为新版 glibc 把__libc_csu_fini等符号挪动了位置Qt 自带的sqlite3使用的旧public链接脚本失效。解决办法是重新生成 sqlite 的合并源文件或者在 configure 时加上-no-sql-sqlite。既然 Telegram 不需要 SQLite直接禁用掉最省事。如果编译中途遇到libclang相关的报错不必理会那是qtdeclarative里的qmltime模块才需要的我们前面用-skip掩盖了它就是避免这条路径。3.4 qscintilla 下载与编译Telegram 依赖里的一个坎Telegram 老版本编辑器使用的是 Scintilla 的高级封装qscintilla你必须单独编译并安装到 Qt 的安装前缀下。qscintilla 这个库比较特殊它的编译脚本叫qmake不是 CMake。下载源码后进入Qt4Qt5目录执行cd /path/to/qscintilla/Qt4Qt5 # 用我们刚才编好的 qmake export PATH/opt/qt5.3.1/bin:$PATH qmake qscintilla.pro -o Makefile make -j$(nproc --ignore1) sudo make installqmake 找 Qt 头文件和库的路径依赖QTDIR或qmake在 PATH 中的位置。这里有个坑如果你没有把/opt/qt5.3.1/bin放在 PATH 前面系统会调用/usr/bin/qmake导致 qscintilla 编译到一半报错找不到 Qt5 模块。确认当前 qmake 版本可以用qmake -v。qscintilla 编译很快大约一分钟。装完之后可以检查一下安装是否成功ls /opt/qt5.3.1/lib | grep qscintilla正常情况下会看到libqscintilla2_qt5.so或类似命名。如果没找到检查Makefile中的INSTALLDIR是否被覆盖或者qmake是否真的指向了我们的安装目录。有时候 qmake 会生成到/usr/lib/x86_64-linux-gnu下这不会影响后续编译但会给 Telegram 链接带来路径问题所以我建议统一安装到/opt/qt5.3.1/lib。4. Telegram 本体编译从源码到可执行文件4.1 获取源码与子模块版本对齐很关键Telegram 官方源码仓库现在叫tdesktop历史上叫Telegram-Desktop。如果你要复现标题里 QT5.3.1 的搭配环境大概率需要切到老版本的 tag比如 1.0.x 系列。这里有一点必须注意不光是主仓库要切 tag所有子模块也要切到对应 commit否则子模块里libtgvoip或qscintilla的接口会和主程序对不上。git clone https://github.com/telegramdesktop/tdesktop.git cd tdesktop git checkout v1.0.8 # 初始化子模块注意要按 commit 对齐 git submodule update --init --recursive如果你已经先跑过一次git submodule update --init --recursive但后来切了 tag系统提示submodule有未提交的修改可以用git submodule update --force --recursive强制对齐。这个操作看起来简单但实际非常容易出错因为子模块的 URL 可能会失效或需要认证。如果看到Unable to find remote helper for https一般是 git 没装libcurl支持重新编译安装 git 即可。4.2 配置构建区分桌面版与移动版Telegram 桌面版的构建系统在 v1.0 时期使用gyp后来才迁到 CMake。这里我们按 gyp 流程走因为只有 gyp 时代才会用到 Qt 5.3.1。在源码根目录下你需要先配置构建目录。cd /path/to/tdesktop/Telegram # 用 gyp 生成 Makefile gyp --depth$PWD --generator-outputout -f make -D target_arch -D host_arch Telegram.gyp--depth$PWD表示以当前目录为相对路径基准--generator-outputout将生成的构建文件放到out子目录-f make指定使用 Makefile 生成器。这里的target_arch留空表示默认架构如果你想在 64 位系统上构建 32 位版本可以设置成ia32但会带来交叉编译依赖新手不推荐。生成完成后进入out目录看到有 Makefile 后开始编译cd out make -j$(nproc --ignore1)这一段 make 的时间取决于你裁剪的 Qt 模块数量。我试过在 8 核 16G 内存的机器上全量编译大约需要 1.5 小时裁剪后可以缩短到 40 分钟。如果中途失败先别急着改代码重点检查日志中链接阶段的命令看看它搜索的 Qt 库路径是否指向/opt/qt5.3.1/lib。可以通过设置环境变量来明确指定export LD_LIBRARY_PATH/opt/qt5.3.1/lib:$LD_LIBRARY_PATH export PATH/opt/qt5.3.1/bin:$PATH4.3 编译命令与参数j 值、输出、调试符号这里我想展开讲一下并行度与输出控制。老手一般直接用make -j$(nproc --ignore1)但内存紧张的机器要注意Qt 和 Telegram 链接阶段每个对象文件都会占用大量内存如果-j值太大系统会频繁 swap导致编译时间反而变长。我的经验是 16G 内存的机器-j8是安全上限8G 内存就用-j4。如果编译过程中发现系统响应变慢立即中断并降低并行度。为了便于定位问题我通常保留两份构建日志make -j4 21 | tee build.log # 编译失败后快速查看最后的错误 tail -n 200 build.logtee build.log会把输出同时打到屏幕和文件这样即使终端缓冲刷新过快也能从日志文件里翻到最关键的报错行。在build.log里搜索error:通常一行就是致命的线索。如果看到undefined reference to基本可以确定是链接阶段库没找到或者符号 ABI 不匹配。调试符号方面如果你想用 gdb 跟踪 Telegram 崩溃现场在Telegram.gyp里找到-DNDEBUG并改成-DDEBUG然后不要加-Wl,-s参数这样生成的二进制会包含调试符号体积大很多但便于后续排查。4.4 首次运行注册、验证码与推送服务的几个注意点编译出来的 Telegram 可执行文件在out/ReleaseTelegram下具体取决于配置直接运行它./out/ReleaseTelegram第一次启动会进入注册流程会要求输入手机号。这里的常见问题是 telegram 收不到验证码。从技术角度说老版本 Telegram 的服务端验证码短信走的是运营商通道如果你所在地区国际短信延迟严重可能等三五分钟才收到。还有一点容易忽略如果你的手机号之前注册过 Telegram 并绑定了别的设备新设备登录时服务端会往那个设备推送验证码而不是发短信。这时候要去旧设备上查看同步验证码或者等验证码过期后再试。另外如果编译时 OpenSSL 版本过新导致 TLS 握手失败界面会一直卡在 “Connecting” 状态。这不是服务器问题而是你的二进制没有正确链接到系统 OpenSSL。用ldd确认一下ldd ./out/ReleaseTelegram | grep ssl正常输出应该包含libssl.so.1.1或libssl.so路径。如果输出是not found说明编译时没有把libssl-dev的头文件目录传进去需要在 Telegram.gyp 或环境变量中指定CPLUS_INCLUDE_PATH和LIBRARY_PATH。关于 telegram注册流程老版本还支持用邮箱作为二次验证这个接口和现在不太一样。如果你是纯离线环境根本连不上服务器那只能先在有网的地方用数据激活一次后面再离线启动。这一点很现实因为 Telegram 客户端启动时会尝试连接配置中心即使你只是看本地缓存内容。5. 编译避坑指南我踩过的 5 个典型问题5.1 现象cannot find -lpublic编译 Qt sqlite 模块时突然出现qt 编译 时候 cannot find -lpublic。这个报错前文提过一次但它值得单独展开。现象是 Qt 在链接qsqlite库时找不到名为libpublic.a或libpublic.so的库。原因是 glibc 2.26 以上移除了__libc_csu_fini等符号而 Qt 5.3.1 自带的 sqlite3 构建脚本里引用了这个旧符号导致生成一个无用的public链接项。解决方式是要么用-no-sql-sqlite禁用 SQLite 模块要么从系统安装libsqlite3-dev并让 Qt 使用系统库在 configure 时加-system-sqlite。对 Telegram 来说它根本不需要数据库直接禁用最省心。如果你必须启用 SQLite那么找一个补丁修改src/plugins/sqldrivers/sqlite/qsqlite3.cpp中的#include qsqlite_public.h为#include sqlite3.h同时删除对public库的链接。5.2 现象编译期异常 undefined reference to std::__cxx11::basic_string这个编译期异常出现在 Telegram 链接阶段报错行形如undefined reference to std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar ::_M_append(char const*, unsigned long)原因是你的 gcc 版本与 Qt 库编译时使用的 gcc 版本不一致。如果 Qt 是用 gcc 7 编译的而其扩展库如 qscintilla 是用 gcc 9 编译的链接时就会因为_GLIBCXX_USE_CXX11_ABI宏定义的不一致出现这种问题。解决的方法是保证所有编译步骤使用同一版本的 gcc/g并在 configure 前统一环境变量。export CCgcc-8 export CXXg-8如果你系统里没有 gcc-8就用apt install gcc-8 g-8。然后重新编译 Qt、qscintilla 和 Telegram字面功夫不能省。还有一种做法是给 CFLAGS 加-D_GLIBCXX_USE_CXX11_ABI0强制使用旧 ABI但这样做可能导致 Qt 库内部声明不一致引发新的问题我很少用。5.3 现象qscintilla 下载与编译后找不到 QScintilla 头文件按顺序编完 qscintilla回头编译 Telegram 时依然报找不到Qsci/qsciscintilla.h。现象是 qmake 明明已经安装成功但 Telegram 的构建脚本还是报错。原因通常有两个第一qscintilla 安装到了/usr/include而 Telegram 的make在/opt/qt5.3.1/include下搜索第二qscintilla 编译时使用的 Qt 版本与我们准备的不同导致头文件带有qt5前缀路径变成include/Qsci/qsciscintillaglobal.h。解决办法是明确指定CPLUS_INCLUDE_PATH与LIBRARY_PATHexport CPLUS_INCLUDE_PATH/opt/qt5.3.1/include:/opt/qt5.3.1/include/Qsci:$CPLUS_INCLUDE_PATH export LIBRARY_PATH/opt/qt5.3.1/lib:$LIBRARY_PATH另外在 qscintilla 的Qt4Qt5目录里可以在 qmake 命令行临时指定安装根目录qmake qscintilla.pro INSTALL_PREFIX/opt/qt5.3.1注意 INSTALL_PREFIX 不是 qmake 固有变量如果这样编译后仍没效果就手动把生成的Qsci目录复制到/opt/qt5.3.1/include下。5.4 现象编译卡死或 OOM编译过程中系统无响应鼠标动不了内存用满最后 ssh 都断掉。这多半是因为并行任务过多。Telegram 编译时最吃内存的阶段是链接Telegram二进制和QtWebKit模块单个链接可能占用 2GB 内存如果同时并发 8 个链接进程16G 内存直接爆。解决方法是分步编译先编译依赖库再编译主程序。我的做法是# 先编译所有子模块 make -j4 -C out/Release submodules # 再编译主程序 make -j4 -C out/Release Telegram如果已经 OOM最简单的方法是降低-j值并加上make -l4参数让 make 在系统负载超过 4 时停止启动新任务。此外用ccache也很有效它能缓存编译产物二次编译时减少 CPU 和内存开销。5.5 现象运行时提示 libicui18n.so.53 找不到编译过了启动时却报error while loading shared libraries: libicui18n.so.53: cannot open shared object file。原因是 Qt 5.3.1 配的是 ICU 53 库而系统新版 ICU 是 63 或 70版本号不匹配。解决方式有三种。第一直接安装旧版 ICU但通常不好找。第二在 configure 时设置-no-icu让 Qt 内部使用自带的最小化 Unicode 处理代价是某些文字显示可能异常。第三设置LD_LIBRARY_PATH指向 Qt 安装目录看/opt/qt5.3.1/lib下是否有libicu*.so.53如果没有说明你 configure 时漏了 ICU 依赖。我觉得最稳妥的方法是回到编译环境补装libicu-dev的旧版本然后重新编译 Qt。注意这里不能部分替换库文件否则会出现二进制兼容性错误。6. 验证构建产物与二次开发我的收尾习惯6.1 用 ldd 检查动态库依赖编译成功不等于能正常运行。我每次拿到新构建的 Telegram第一件事就是执行ldd检查动态库依赖判断它是否找得到所有必需库。重点看libqt5相关库是否指向/opt/qt5.3.1/lib以及libssl、libicu是否是预期版本。ldd out/ReleaseTelegram | grep -E qt|ssl|icu|scintilla如果列出的路径有不存在的文件用LD_LIBRARY_PATH补充并做一次ldconfig刷新缓存。这一步能避免把二进制带到别的机器上后出现一堆 “versionGLIBC_2.29not found” 的尴尬。6.2 调试符号与崩溃日志gdb 快速定位当程序启动时黑屏或闪退我一般会用 gdb 捕捉现场。由于我们的 Qt 是 release 编译函数名可能被优化但崩溃时调用栈依然能提供线索。gdb --batch -ex run -ex bt --args ./out/ReleaseTelegram如果输出显示Segmentation fault发生在QApplication构造之前多半是 xcb 平台插件没找对。检查 Qt 的 platform 插件路径ls /opt/qt5.3.1/plugins/platforms/libqxcb.so没有这个文件就重新编译qtbase插件并确保安装目录里有它。另一个常见崩溃是字符编码问题在启动前设置QT_IM_MODULEibus或fcitx可避免部分输入法导致的崩溃。这种问题很玄学但 gdb 能给一个明确的框架。6.3 进阶用法裁剪模块、自定义构建脚本如果你拿这个构建产物不是为了日常聊天而是嵌入到某台工控机里建议进一步裁剪关闭自动更新修改默认配置只保留基础 UI。老版本 Telegram 支持在构建时通过.args文件关闭DESKTOP_APP_USE_PACKAGED或者手动在代码里禁用某些联网功能。我自己的习惯是把整个构建命令封装成一个build.sh固化环境变量、configure参数和make步骤这样下次环境重置后能复现。下面是我常用的骨架#!/bin/bash set -e export PATH/opt/qt5.3.1/bin:$PATH export LD_LIBRARY_PATH/opt/qt5.3.1/lib:$LD_LIBRARY_PATH ./configure -prefix /opt/qt5.3.1 -opensource -confirm-license -release \ -shared -qt-zlib -qt-libpng -qt-libjpeg -qt-xcb \ -skip qtwebkit -nomake examples -nomake tests make -j4 make install cd /path/to/qscintilla/Qt4Qt5 qmake qscintilla.pro make -j4 make install cd /path/to/tdesktop/Telegram gyp --depth$PWD --generator-outputout -f make Telegram.gyp cd out make -j4 Telegram这套脚本在 8G 内存的旧机器上也能跑下来关键是make -j4而不是贪多。前两年我拿旧源码在新系统上折腾反复踩坑后养成了记录环境变量和参数的毛病每次都能少花两个小时。希望这些经验能帮你少走一点弯路早日跑通自己的 Telegram 二进制。希望帮到你。本文还有配套的精品资源点击获取