stop building the wheels!
This commit is contained in:
@@ -0,0 +1,58 @@
|
||||
## 问题
|
||||
|
||||
### 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` 维护的映射关系决定, 格式类似:
|
||||
|
||||
```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` 符号链接的条目:
|
||||
|
||||
```toml
|
||||
"/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:
|
||||
|
||||
```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 构建的项目可能需要较大幅度地修改编译参数和流程, 实用价值不高.
|
||||
+3
-1
@@ -139,6 +139,7 @@ chafa
|
||||
chaotic-keyring
|
||||
chaotic-mirrorlist
|
||||
chromium
|
||||
chwd
|
||||
claude-code
|
||||
cloc
|
||||
cmake
|
||||
@@ -199,6 +200,7 @@ frei0r-plugins
|
||||
fuzzel
|
||||
fzf
|
||||
gamemode
|
||||
gcc14
|
||||
gdb
|
||||
gdu
|
||||
gearlever
|
||||
@@ -292,7 +294,6 @@ linux-firmware
|
||||
linux-lts
|
||||
linux-lts-headers
|
||||
linuxqq
|
||||
llama.cpp-cuda-git
|
||||
llmfit-bin
|
||||
localsend
|
||||
lolcat
|
||||
@@ -306,6 +307,7 @@ man-pages
|
||||
mangohud
|
||||
matugen
|
||||
meson
|
||||
mkvtoolnix-cli
|
||||
modprobed-db
|
||||
moonlight-qt
|
||||
moreutils
|
||||
|
||||
Reference in New Issue
Block a user