On Wed, Jan 30, 2013 at 2:58 PM, Stephan Beal <sgb...@googlemail.com> wrote: > On Wed, Jan 30, 2013 at 8:45 PM, Sergei Gavrikov <sergei.gavri...@gmail.com> > wrote: >> >> Incidentally, there is another opinion, Never use static linking! >> >> http://www.akkadia.org/drepper/no_static_linking.html > > > On a related note, Solaris 10 removed static versions of their system > libraries, due to a long history of statically-linked binaries causing (in > the words of one of the articles below) "pain and ruin": > > https://blogs.oracle.com/rie/entry/static_linking_where_did_it > http://stackoverflow.com/questions/7024730/from-static-to-dynamic-linking-on-solaris-10
It not only made those problems go away, but it also improved system performance, particularly boot times, because the common code (the libraries) got loaded once instead of once per-executable. The problems that Solaris 9 and earlier had with mixed dynamic and static linking are shockingly similar to problems one sees on Linux today. The typical example is a program that is single threaded and linked statically with libc but also with libdl, and then some part of the program ends up doing a dlopen() of a library that needs pthreads. Interesting things happen then. A number of Solaris 9 system libraries had lots of code whose only purpose was to deal with the transition from one process model (single-threaded) to the another (multi-threaded), occasioned by the loading of a dynamic shared library. This doesn't mean that you shouldn't want or can't have static linking. It means you shouldn't insist on statically linking *system* libraries, but you can have libsqlite3.a. Also, the main problem that arises from using dynamic linking is DLL hell. The simplest solution to that is direct binding (Solaris) or versioned symbols (Linux) -- you get static link semantics (no DLL hell) with the benefits of dynamic linking (such as not having to rebuild to benefit from a bug fix in a library, as well as explicit interposition via LD_PPRELOAD, and overall performance improvements). Nico -- _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
