直接用appimage使用呢

是什么软件呢？

就是appImage,依赖GLIBC_2.39

隔壁都升到2.43了
咱也该升一下啦

用mint,包虽然也不算新，至少我还没遇到过包版本过旧的问题

什么appimage软件必须要求GLIBC 2.39+

怕不是rust写的罢

abl可解

https://gitee.com/spark-store-project/additional-base-lib

有2.39就会有2.40、2.41、2.42.....追到什么时候？每次底层都大升一次？
那建议你用flatpak，玲珑包这些容器。

有这神器？有空试试

其实我一直觉得你们这套库该更新了

该更新的不是库，是方法。

AnyLinux那个项目专门有个说明，介绍了外挂glibc的主要难点和他们用的解决方式，最重要的是，为什么他们选择这一套解决方式。

你们这套库你是接手的，而上一位作者实际上只是实现了这个效果，没有经过大量测试，没有更深入的比较多种方法的优劣。

使用./ld-linux.so这种方式来使用动态链接器是很有风险的，1是patchelf并不是完全可靠的工具，很多时候他都会把二进制搞坏，这很常见。2是使用./这种相对路径本身就很有风险，程序本身的逻辑如果存在目录跳转，就会导致./的指向发生变化，从而找不到链接器。

使用./ld-linux.so这种方式来使用动态链接器是很有风险的，1是patchelf并不是完全可靠的工具，很多时候他都会把二进制搞坏，这很常见。2是使用./这种相对路径本身就很有风险，程序本身的逻辑如果存在目录跳转，就会导致./的指向发生变化，从而找不到链接器。

bwrap会启一个轻量级容器并把指定的文件(也就是链接器和glibc相关库)挂载替换掉。对于容器内的应用，他们直接找到的链接器就是abl的连接器。

因此abl从原理上就不存在你说的patchelf或相对路径问题。ABL是一个轻量容器，而不是一个修改二进制或链接器工具，可以认为ABL是一个极简的，只包含了链接器和glibc的类似docker容器的解决方案

patchelf只在abl打包阶段使用，而且也不会用于修改二进制，只是读取interpreter，用来给不同发行版打包而已

实际上，除了AnyLinux AppImage的魔改连接器方案，还有一种appimage也可以实现在接近任何发行版上运行，那就是 Conty Appimage的自带容器方案

https://gitee.com/amber-ce/Conty

ABL ACE APM都是走的这样的容器方案，我们整体的技术方案都是基于此进行的。当然，不像anylinux完全不依赖容器，可以在远古发行版和内核上运行，但至少Ubuntu 18.04以上能用

在一些不能使用容器的情况(如安全软件，奇怪的类Linux环境(安卓，鸿蒙等))下，使用anylinux的方案是更加通用的，但这些情况暂时我们也不考虑主线支持

以稳定著称的debian 13 stable，glibc版本都是2.41了。TESTING更加高。

rust 开发者狗的很，Build 开始的时候不提示 glibc 版本，build 过程中崩，大大的浪费时间。