AppImage 就算是在包里添加了高版本 libc 也会提示段错误

appimage 就算是在包里添加了高版本 libc 也会提示段错误;那这东西到底有什么卵用呢;最根本的问题都无法解决,虽然 libc 是基础,但是如果无法解决这个问题那么 appimage 和那些散装软件比有什么优势呢?哦,依赖关系比那些散装软件解决的好一点点而已 :grin:

提示 libc 和 libm 版本不够,15.1 正好是 2.26


添加了 libc libm2.28

提示段错误了

垃圾; :confounded:

我是风滚草 KDE,Viber 的 AppImage 无法输入中文。我只好在 Kate 中先敲好中文,再拷培到 Viber。。。

@fenglelyng

  1. 你要 100% 确认你 bundle 了全部 glibc 及之上的包。glibc 是最基础的那个包,基本上全部的包都依赖它。也就是说你需要一整个 tree 而不是一两个 .so…appimage 只要用了 15.1 上的任何一个库文件都会 segfault…

  2. 你可能还需要替换 AppImage 里面的 AppRun…

AppImage 制作的时候是有一个宿主系统的,AppRun.c 是使用那个系统的 glibc 编译的,很明显那个系统应该是 Ubuntu 20.04…glibc 版本比 Leap 15.1 高…入口出现问题 ISO 里面 bundle 什么都没用…

所以制作 AppImage 才麻烦,因为要找一个足够旧的系统做宿主…BTW,我是第一个在 openSUSE 上搞 AppImage 的人,后来不搞了就是存在这个缺陷,现在 OBS 自动生成的 AppImage 其实没什么用,比如你从 TW 源里下载 AppImage,宿主就是 TW,这么新的宿主没什么受众的…

1赞

@Princeviolin 你需要的是拆开 AppImage,看看 Qt 的版本,然后用对应 Qt 编译一个 libfcitxplatformimcontextplugin.so 丢进去,再重新打包

1赞

刚看了一下,几大发行版里 openSUSE Leap 的 glibc 版本最老,debian10 和 rhel8.3 都是 2.28,如果在这些平台做 appimage,那么就无法在 Leap 上用?

@RestInPieces 已经是 2021 年了,开个容器或者虚拟机又不难,发布应用更是应该用自动化的方式来。弄个旧版的操作系统就是输入版本号的事情。用特别新的操作系统来制作 Appimage 就是搬起石头砸用户的脚,和 Appimage 的本意背道而驰。

他们文档里就特别说明应该用尽可能古老的系统来弄,或者用一些特别的处理方法。那些用超级新操作系统制作的都是在 Appimage 这方面的 noob.

  1. 你能用 RHEL?
  2. 你为什么要用 Debian 10?

AppImage 很明显针对的不是滚动发行版,针对的是 Release Distribution。那很明显你需要在 LTS 里面找个最老的。我个人的建议是 CentOS 6 或者 Ubuntu 18.04。Leap 15.1 都太新了 :joy: 我都考虑过 SUSE 11。只有这样才能保证用到 glibc 的子集最小。

@RestInPieces 或者还有一个办法,搞静态 musl c,然后搞静态 clang。像 cross-compile 那样弄一套静态 toolchain。然后编译软件,最后把 musl c 的 .a 什么的一起丢进去。同时 AppImageKit 本身也是 musl c 编译的静态版本,生成的 AppRun 也是 musl c 的静态版本。这样就不在五行中了。

纯 C/GTK 可以这么干,C++/Qt 要费很大力气。

steam 就做了一个容器;用来在新系统上兼容老游戏的;就是 steam play runtime

感谢女神!