apache用户通过shell_exec调用wkhtmltopdf报libstdc++版本缺失错误

你遇到的报错和库本身缺失无关，核心是动态库搜索路径优先级冲突：
XAMPP（对应路径/opt/lampp）启动Apache时，会主动把自身的专属库目录/opt/lampp/lib注入到动态库搜索路径LD_LIBRARY_PATH的最高优先级位置。
你在终端直接运行wkhtmltopdf时，用的是系统原生路径下的libstdc++.so.6，版本足够满足依赖，所以运行正常；但PHP通过Apache执行命令时，wkhtmltopdf会优先加载/opt/lampp/lib里自带的旧版本libstdc++.so.6，这个旧版本文件里没有报错信息提到的GLIBCXX_3.4.21、CXXABI_1.3.9等符号，就会触发大量版本不匹配的报错。

你可以在终端跑两条命令确认问题：

• 查看XAMPP自带libstdc++支持的版本符号：
  strings /opt/lampp/lib/libstdc++.so.6 | grep GLIBCXX
  输出的最高版本一般只到GLIBCXX_3.4.19，完全覆盖不了报错需要的版本
• 查看系统原生libstdc++支持的版本符号：
  strings /usr/lib/x86_64-linux-gnu/libstdc++.so.6 | grep GLIBCXX
  这里面会包含所有报错提示缺失的符号，和终端直接运行wkhtmltopdf正常的表现完全对应。

方案1：命令执行时临时修正库搜索路径（零侵入，最推荐） #

不需要修改任何系统、XAMPP的原有配置，只需要在PHP调用命令的时候，把系统原生库路径放到搜索优先级的最前面，临时压过XAMPP的旧库路径即可。
把原来的PHP代码改成：

// 临时注入系统库路径到搜索优先级最高位，再执行wkhtmltopdf
$command = 'export LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu:$LD_LIBRARY_PATH && wkhtmltopdf /path/to/file.html /path/to/output/file.pdf 2>&1';
echo shell_exec($command);

注意：

• 32位系统请把系统库路径替换为/usr/lib即可
• 命令里的输入、输出文件路径尽量使用绝对路径，避免因为Apache进程的工作目录和终端不一致，出现文件找不到的问题
  这种方式只在当前这次命令执行周期内生效，完全不会影响XAMPP自身组件的正常运行，也不会留下配置残留。

方案2：替换XAMPP目录下的旧libstdc++文件（有一定侵入性） #

如果不想每次写命令都加路径前缀，可以直接把XAMPP里的旧版libstdc++替换成系统的新版本：

1. 先备份原旧库文件，避免兼容性问题：
   mv /opt/lampp/lib/libstdc++.so.6 /opt/lampp/lib/libstdc++.so.6.bak
2. 创建软链接指向系统新版本库：
   ln -s /usr/lib/x86_64-linux-gnu/libstdc++.so.6 /opt/lampp/lib/libstdc++.so.6
   风险提示：这个操作会全局替换XAMPP环境下的C运行库，如果XAMPP内置的PHP、Web服务器等组件依赖旧版libstdc的特定行为，可能会触发兼容性故障，操作前一定要做好文件备份，出问题可以直接把备份文件改回来还原。

方案3：编译时为wkhtmltopdf指定固定库搜索路径（适合长期稳定部署） #

如果是自行编译wkhtmltopdf的场景，可以在编译阶段通过链接参数指定优先加载的系统库路径，让wkhtmltopdf不管当前环境的LD_LIBRARY_PATH如何配置，都固定从系统路径加载libstdc++。不过如果是直接使用官方发布的二进制包，这个方案操作成本很高，一般不推荐普通用户使用。

• 不需要额外安装系统libstdc++相关的依赖包：你的系统里已经有满足版本要求的库了，问题本质是加载了错误位置的旧库，不是真的缺库
• 不要一开始就怀疑权限问题：你当前的报错全部是动态库版本不匹配的提示，和Apache用户的文件读写权限没有关系，等库路径问题解决后再排查权限即可
• 可以在PHP里执行echo shell_exec("echo $LD_LIBRARY_PATH");验证：返回的路径列表里如果/opt/lampp/lib排在最前面，就完全印证了路径优先级冲突的判断。

内容的提问来源于stack exchange，提问作者Pietro Siccardi