The issue of static vs. dynamic linking keeps coming up in relation to building of MariaDB (and MySQL). I thought I would share some thoughts on this. There is a tradition for linking statically in MySQL for performance and other reasons. However, these days there are a number of problems with static linking, to the extent that I think static linking of system libraries is really impractical. Now, in a *fully* static binary that does not load any shared libraries at run-time, static linking works ok. However, in most real-life situations, there is always some amount of dynamic linking: - Nowadays glibc uses dynamic loading at runtime to handle NSS. And while this can be disabled, it is strongly discouraged: http://gnu.gds.tuwien.ac.at/software/libc/FAQ.html#s-2.22 - Support for dynamic loading of pluggable storage engines requires dynamic loading at runtime. - Even just installing a single UDF (user-defined function) into the server requires dynamic loading of a shared library. - Client libraries (libmysql, libmysqld) may be used in dynamic shared objects built by users (like the Amarok plugin using libmysqld). So a binary built for general distribution really has no choice but to support some dynamic linking (users building on their own can do differently, of course). The problem now is the following: Consider a binary B that loads a dynamic shared object S. Assume that both B and S use the same library L. Now if B links L statically, part of L, but not necessarily all of it, will be included inside B. These parts of L will be of some version v1 of L determined when B was built, and they will be visible to S. But S may use other parts of L not included in B, and these may be of a different version v2 of L, as determined by how S was linked and loaded. The result is that S will be using a mix of two different versions of L. This very rarely work. Typically, L will be eg. libc, and B will contain parts of libc from the build machine, while S will use the libc installed on the machine on which B is run. This is the basic problem. Because of the way linking works in Linux and similar systems, libraries used by dynamically loaded objects must themselves be linked dynamically to avoid this problem with mixed versions. This applies to things like libc and libz. On the other hand objects that are internally part of MariaDB (libmystrings, libmyisam, etc.) are no problem to link statically. There are also a number of bugs on MySQL relating to this. So it is not just an academic problem. The conclusion as far as I can see is that for MariaDB binaries, we should link system libraries dynamically, or things will just not work correctly for our users. Unless someone knows a way to avoid these problems. ----------------------------------------------------------------------- Just to recap, the main benefits of static linking are, to my knowledge: 1. Performance. On i386, position-independent code (as needed in shared objects) needs code like this in the prologue of every function that accesses global names (like calling other functions): call label label: pop %ebx This consumes cycles, and reduces available registers on an already register-starved architecture. 2. System independence. Upgrading system libraries on the host does not affect the application, eg. less change of breakage due to incompatibility (though this can be also a disadvantage in case of eg. security fixes). As far as I know, nowadays, these advantages are much smaller: 1. On x86_64, the CPU architecture has been fixed to support position-independent code with little or no extra overhead (like pc-relative addressing modes). 2. Glibc has become much better at preserving binary compatibility across versions. ----------------------------------------------------------------------- Hope this helps, - Kristian.