4 ms·
Application binaries must statically link libc and ssl when making programs for packging into appimage?
by tosseraccount 11y ago
Application binaries must statically link libc and ssl when making programs for packging into appimage?
- hundchenkatze 11y agoMaybe not, but Since "Every AppImage contains an app and all the files the app needs to run." Even if you were dynamically linking, you'd be linking against a lib contained in the AppImage. So, each app would still have its own glibc that would have to be updated.
- tosseraccount 11y ago"The AppImage needs to include all libraries and other dependencies that are not part of all of the base systems that the AppImage is intended to run on" [ https://github.com/probonopd/AppImageKit/wiki/Creating-AppImages https://github.com/probonopd/AppImageKit/wiki/Creating-AppIm... ]
- kiallmacinnes 11y agoI haven't dug far enough into this specific project to know if it's static or dynamic linking, but that just doesn't matter. Each app has it's own copy of libssl etc embedded into the prepackaged "binary" which is executed.. That's enough to know it's going to lead to all sorts of suffering when you actually try and rid yourself of $CVE of the month.
- probonopd 11y agoYou can use either static or dynamic linking. An AppImage is really just an ISO container wrapping around your binaries.
- kiallmacinnes 11y agoSo, yea.. As I said, in this context, it just doesn't matter if your statically or dynamically linked against glibc, every single AppImage published before Feb 15th or so requires an update. What percent of AppImage's in the wild have shipped an update? Of those, how many have updated previous stable releases rather than just the latest version? I suspect very few. [EDIT - Typos]
- jjuhl 11y agoRegardless of dynamic or static linking there's the fact that "users dont upgrade" so you've lost either way.
- deleted 11y ago[deleted]