3 ms·
It's a two sided coin, if you update a dynamically loaded library that subtly breaks backwards compatibility, you end up with apps that mysteriously stop workin
by CoolGuySteve 13y ago
It's a two sided coin, if you update a dynamically loaded library that subtly breaks backwards compatibility, you end up with apps that mysteriously stop working because of some other update in the system.
Really, it's up to the app maintainer to update their program, and if it has a vulnerability, in theory the sandbox will prevent it from doing damage to others.
- binarycrusader 13y agoIf someone updates a library incompatibility, they deserve what they get. That's why shared libraries have versioning. In the mobile space, it would be even more beneficial if platform holders and ISVs actually followed this; the memory and space usage savings could be substantial.
- binarycrusader 13y agoI'm uncertain why someone would downvote my comment above, but shared library versioning is a real thing, and it is a best practice: http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries... https://www.usenix.org/legacy/publications/library/proceedings/als00/2000papers/papers/full_papers/browndavid/browndavid_html/ https://www.usenix.org/legacy/publications/library/proceedin... Linux distributions heavily depend on this for the GCC runtime libraries (such as libgcc_s); it's how they provide backwards compatibility. Many operating system distributors also rely on symbol versioning for their shared libraries as well so they can compatibly evolve interfaces for consumers. So my original point stands, if someone incompatibly updates a shared library without accounting for versioning, they're doing it wrong.