AlpineLinux 使用 MUSL 而不是 GLIBC。 MUSL 更轻,并且不会拖累遗产。当应用程序依赖于遗留系统时(例如当它们想要使用 pthread 时),这是一个问题。
AlpineLinux 有一个 wiki,描述了运行需要 GLIBC 的应用程序的 4 种替代方案。
https://wiki.alpinelinux.org/wiki/Running_glibc_programs https://wiki.alpinelinux.org/wiki/Running_glibc_programs
其中一种选择是使用社区贡献的 gcompat 包。 APK 包、描述和其他详细信息位于 pkgs 页面上
在 APKBUILD 文件中,它显示了源代码的来源,并且 compat 库中的 pthread 没有 __pthread_register_cancel。在您的堆栈跟踪中,我没有看到任何对 /lib/libgcompat.so.0 的引用,因此也许仍然需要通过运行 ldconfig 来找到该库,但我认为 gcompat 不包含所有 pthread 方法。它只是不在代码中
https://git.adelielinux.org/adelie/gcompat/-/blob/current/libgcompat/pthread.c https://git.adelielinux.org/adelie/gcompat/-/blob/current/libgcompat/pthread.c
我依稀记得我曾经在 AlpineLinux 中安装过 GLIBC 软件包,但这可能只是我的疯狂梦想之一,我在存储库中找不到这样的软件包
我找到的是 Sasha Gerrand 提供的 APK 和 Docker 镜像,她为 AlpineLinux 创建了完整的 GLIBC 2.34 库。如果您安装APK包或使用Docker镜像,您应该在AlpineLinux上运行完整的glibc。
https://github.com/sgerrand/alpine-pkg-glibc https://github.com/sgerrand/alpine-pkg-glibc
就我个人而言,我会尽量避免运行依赖于库的应用程序,但我知道有时并不是切换到更灵活的应用程序的选择。