宝塔申请 SSL 报 curl undefined symbol：一份旧 libcurl 残留惹的祸
宝塔申请 SSL，报 curl: undefined symbol: curl_global_trace上周在一台宝塔机上申请 SSL 证书，报错大概是这样：
curl: undefined symbol: curl_global_trace
第一反应是「curl 装坏了」，`curl -V` 一看版本号正常，命令行手动跑 `curl https://...` 也没事。但一到宝塔里申请证书就走不通。
先看它到底加载的是哪个 curl
光看 `curl -V` 不够，得看动态链接实际命中的库：
ldd $(which curl) | grep curl
ldconfig -p | grep libcurl
这一看就露馅了：系统缓存里命中的是 /usr/local/lib 下的一份 7.64.1，而系统自带的 curl 其实是 8.5.0。旧库里根本没有 `curl_global_trace` 这个符号（8.x 才加），于是「符号未定义」。
踩的坑，重点说
定位到旧库以后，我第一反应是把那个文件改名成 `.bak`。结果——没用。
原因是 ldconfig 认的是库里的 soname，不是文件名。你把文件名改了，它内部的 soname 还叫 `libcurl.so.4`，缓存照样把它认成 libcurl。删软链也不行，`ldconfig` 会照着 soname 把软链重建回来。
绕了一圈才明白，正解只有一个：把这份旧库整个挪出 /usr/local/lib（挪到别的目录），再跑一次 `ldconfig` 刷新缓存。让它彻底不出现在搜索路径里，问题立刻就好。
https://blog.7ehl.com/usr/uploads/2026/10/2743245429.png
复盘
· 这种「读出来不对、跑起来也说不清哪里不对」的链接层问题，别猜，先 `ldd` + `ldconfig -p` 把实际加载路径摆出来；
· 两个同名库抢位置时，版本身份由 soname 决定，改文件名/删软链都是自欺欺人；
· 能装两套 libcurl 的机器，多半是以前编译装过东西留下的 — 装完把临时库清干净，能省掉以后这一整出。
机器多的时候这类「库层」问题最烦，一台台上去 `ldd` 很费劲。我们平时用批量远程管理工具（RdpManager）批量连上去看，至少省掉反复登录的功夫；不过库冲突这种事，还是得一台台看输出、对版本。
（全程只用了一台客户机，IP/域名就不放了。） 这类「命令行没事、面板里报 undefined symbol」的，基本可以锁定成老版本 .so 被优先加载了。用 ldd $(which curl) 看它实际链到哪个 libcurl，重点看 /usr/local/lib 下是不是躺着一份旧的——宝塔自带的 PHP/curl 常把它塞进 ld.so.conf，还排在系统库前面。
顺手一个习惯：装/升级过第三方源的东西之后，ldconfig -p | grep libcurl 看一眼有几份，发现多份就该警惕。
页:
[1]