4 ms·
You can, the trouble is that you don't know that say, libfoo.so loads libbar.so at runtime, and so you need to also package up libbar.so. Otherwise, libbar.so
by dale_glass 3y ago
You can, the trouble is that you don't know that say, libfoo.so loads libbar.so at runtime, and so you need to also package up libbar.so.
Otherwise, libbar.so won't be found in your AppImage, will get loaded from the host instead, and now it explodes but only on some distributions.
In my case it was OpenSSL loading stuff at runtime.
- duped 3y agoIn general a program that calls `dlopen()` must either ship with the libraries being opened (in the case of OpenSSL, which iirc only does this with libcrypto or one of its targets in some cases?) or be able to resolve them without the help of the loader via default paths. But all that said if you don't want your app to explode on different distros you always need to vendor your dependencies, including transitive dependencies. That's just the sad reality of shipping programs that are dynamically linked.
- dale_glass 3y agoYeah, that's kinda the problem. If your dependencies are complex enough you may have a tough time figuring out when you've packaged everything. Surprises may be lurking anywhere. It might be loading files based on something read from a config file, or concatenating tokens, so you'd have a hard time knowing you got everything for sure without reading the source for every library your application loads, and every library your direct dependencies load. And then everything may still work until 3 distro releases later something finally becomes binary incompatible.
- account42 3y agoTo be hones, developers should be doing that work anyway to figure out what dependencies they really need and which ones can be replaced by lighter ones that don't pull in gigabytes of crap. And also the situation isn't really different on Windows except that you have to do it from the start because there is no illusion of the base system providing a bunch of random libraries for you.