-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Handle AppImages that bundle everything #12
Comments
This application assumes that the blacklist is being respected. This "bundle all" stuff simply isn't standardized, there's no way to reliably detect that (it's a mess!). The glibc ABI check is correct in the sense that the app's binaries require a newer libc. You cannot know whether such a libc is contained in an AppImage, and you cannot ensure that even if that's the case, this will then be loaded. Arguably the (human readable) message of the check isn't totally correct. I don't see how this edge case could be supported without significant work and making too many assumptions over the AppImage's workflow. This is a static analysis tool, and doesn't employ runtime checks. Let's call this a false negative. |
Simple:
Why? Just check for it... |
That's not sufficient IMO. You also need the linker. And that stuff must then also be used actually. What if some script just copies it into some random, pointless location and it's never used? |
OK, some more checks ;-) |
Although we generally don't recommend it, some projects have good reasons to build AppImages that bundle everything. This is especially true for applications that cannot be built on older LTS build systems, but where the intended audience includes users with such systems. Prominent example: Inkscape.
When you run the official Inkscape AppImage through this tool, however, you get
This is not correct. If you try it out you will find that this AppImage in fact does run on those systems.
The text was updated successfully, but these errors were encountered: