Am 27.09.2013 14:56, schrieb Chris Down:
Well, static libraries are not a waste of space if it was intentional. Static linking should be preferred for a number of reasons[0], they should be preferred in any sane Linux distribution (of which, unfortunately I can't name any at the moment until stali comes out).
Aren’t statically linked executables less secure?
Several people argue (with implicitly requiring ABI-stability) that dynamically linked executables benefit from security fixes in libraries
Nothing about using static libraries is sane. That FAQ seems to be about some bitterness about glibc and its code, which has nothing to do with static and dynamic linking. Now, to the key point: they depend on. What "some people argue" is true. If there is a vulnerability in zlib (which actually happened a few years back), all that is needed is to rebuild zlib and be happy. A statically linked system would need to find every single binary that incorporates zlib and rebuild it.
This is true to some extend, but if there is a security flaw in a dynamically linked library, all programs are affected as well; whereas statically executables aren’t.
We know that there is some overhead in re-compiling all affected executables if a dependent library is insecure, but we don’t see this as a critical disadvantage, because we also focus on a small and
This is the biggest pile of nonsense I ever read. If there is a flaw in a library, all programs that use it are affected - including statically linked executables that were built using that library. It is even worse: There is no easy way to determine which version of the library a specific binary was built against. This is a security nightmare. maintainable userland, where only one tool for each task exists. On a system like Arch that includes a several desktop environments, web servers, web browsers, ... (tons of other stuff), that statement is simply nonsense. In the 1970s, you would call the 'gzip' (or even 'decompress') binary to decompress a file, but in the year 2013, you use a library API for that because it is more convenient, less error-prone and more efficient. The 'one tool for each task' has long become 'one implementation for each task', but that implementation is no longer in a binary, but in a shared/static library. If you really insist on the old way of doing things, you will be unable to use any modern program because they don't follow the old 'one tool' paradigm anymore, they don't call external programs. As an Arch user, you would first have to rewrite pacman to not use libarchive, but to use xz, gzip and tar to handle packages and package databases. After you've done that, you can start talking about statically linking those tools - but at that point, pacman will already be too slow to be usable in any way.