3.6 KiB
问题
VapourSynth 破坏性更新
Mon May 4 19:25:48 CEST 2026
-
vapoursynth包更新至 75 版本后 (此问题其实是 R74 引入的, 但他们似乎跳过了 R74 直接在今天更新至 R75), vsscript 库文件符号链接关系如下:/usr/lib/libvapoursynth-script.so->python3.14/site-packages/vapoursynth/libvsscript.so/usr/lib/libvapoursynth-script.so.0->python3.14/site-packages/vapoursynth/libvsscript.so
这导致 ldconfig 根据 SONAME 字段建立的缓存条目变化, 例如从
libvapoursynth-script.so.0 (libc,x86-64) => /usr/lib/libvapoursynth-script.so.0变为libvsscript.so (libc6,x86-64) => /usr/lib/libvsscript.so, 从而使其他未能重新链接的程序找不到对应库. -
同时, 插件目录也从
/usr/lib/vapoursynth/改为/usr/lib/python3.14/site-packages/vapoursynth/plugins/, 很多包未能及时更新插件安装路径, 导致 vapoursynth 插件丢失. -
vapoursynth 不再在编译器 link libpython, 而必须在加载 libvsscript.so 时选择 python. 选哪个 python 由
$HOME/.config/vapoursynth/vapoursynth.toml维护的映射关系决定, 格式类似:"/usr/lib/python3.14/site-packages/vapoursynth/libvsscript.so" = ["/usr/bin/python","/usr/lib/libpython3.14.so.1.0"]可以运行
vapoursynth config自动更新.然而, 上文提到过新的 libvsscript.so 的 ldconfig 条目是
libvsscript.so (libc6,x86-64) => /usr/lib/libvsscript.so, 而vapoursynth config只会在vapoursynth.toml写入/usr/lib/python3.14/site-packages/vapoursynth/libvsscript.so的条目. 此时, 如果加载 libvsscript.so, 会从 ldconfig 拿到/usr/lib/libvsscript.so，而 vapoursynth 在拿到此路径后不解 symlink, 查vapoursynth.toml时和任何条目都对不上, 导致加载失败. 报错类似:Python executable and library path couldn't be determined despite automatic configuration. Run `vapoursynth config` to set it for this Python installation and then try again.临时修复方式为在
$HOME/.config/vapoursynth/vapoursynth.toml里手动加上针对/usr/lib/libvsscript.so符号链接的条目:"/usr/lib/libvsscript.so" = ["/usr/bin/python","/usr/lib/libpython3.14.so.1.0"]
CUDA 13.2 不兼容 GCC 16.1
Mon May 4 15:39:17 CEST 2026
nvcc 和 gcc 兼容问题的历史重演. 随 GCC 16.1 发布, 以前用 GCC 15.2 能够编译的 CUDA 包会报一堆错误, 影响范围非常大.
解决方法为装 gcc15 等旧版本工具链, 并修改编译流程使 nvcc 使用指定编译器. 例如对于部分 Makefile:
CUDA_CCBIN ?=
cudaccbin = $(if $(CUDA_CCBIN),-ccbin $(CUDA_CCBIN),)
...
nvcc $(cudaccbin) ...
但这样会带来一个问题: gcc15 是 AUR 包, 需要编译. 而这并不会是一个很愉快的过程. 除去超大的仓库体积, 超长时间的编译测试和超高的资源占用外, 过程中还可能会因为各种问题失败, 修复问题后可能还需要从头再来, 成本过高.
但好在 cachyos 有打包 gcc14 二进制包, 因此再降一个版本即可绕过编译过程. 但 AUR 上的众多打包者应该还是会选择 gcc15, 因此在有仓库打包 gcc15 二进制包或 NVIDIA 更新 CUDA 支持 GCC 16 之前, 几乎所有涉及 CUDA 的包仍然需要手动修改 PKGBUILD 构建.
另外还有几个可选方案:
- 可以用 clang++ 代替 nvcc, 但支持程度似乎有限 (
clang++: warning: CUDA version is newer than the latest partially supported version 12.9 [-Wunknown-cuda-version]), 且对于部分已经在使用 nvcc 构建的项目可能需要较大幅度地修改编译参数和流程, 实用价值不高.