portability: static vs. shared? - Unix

This is a discussion on portability: static vs. shared? - Unix ; Hello, My naive common sense and a few authors[1] say that linking libraries statically makes program binaries more portable. However I have seen it written here on c.u.p[2] that static linking a makes programs *less* portable. Would anyone care to ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: portability: static vs. shared?

  1. portability: static vs. shared?

    Hello,

    My naive common sense and a few authors[1] say that linking
    libraries statically makes program binaries more portable.

    However I have seen it written here on c.u.p[2] that static
    linking a makes programs *less* portable.

    Would anyone care to explain *why* statically linking
    libraries might make programs less portable than linking
    dynamically?

    Thanks,

    [1] - http://www.ccp4.ac.uk/peter/programm...ecutables.html
    - "Understanding the linux kernel, 3rd ed.", D.P. Bovet and M.
    Cesati, O'Reilly, 2006, p.817
    [2] http://tinyurl.com/6cls6k

    --
    JR

  2. Re: portability: static vs. shared?

    Jean-Rene David wrote:
    > Hello,
    >
    > My naive common sense and a few authors[1] say that linking
    > libraries statically makes program binaries more portable.
    >
    > However I have seen it written here on c.u.p[2] that static
    > linking a makes programs *less* portable.
    >
    > Would anyone care to explain *why* statically linking
    > libraries might make programs less portable than linking
    > dynamically?


    There is a lot more heat than light on this subject and it mostly
    derives from the failure to make a crucial distinction between *system*
    libraries and *third-party* libraries. Discussion of static vs shared in
    the absence of this distinction makes little sense.

    System libraries should generally be linked shared, and in fact the
    trend is toward making that the only option (e.g. Solaris no longer
    ships static system libraries). Third-party application libraries, on
    the other hand, may reasonably be linked statically. This is more of a
    personal preference sort of thing in which a case can be made both ways.
    Personally I like to statically link third-party code such as zlib and
    libcurl because it removes a lot of moving parts which could break in
    the presence of other versions of the same library. But that's where it
    gets philosophical: having more flexibility can be a feature or a bug,
    and shared linking provides that flexibility.

    So perhaps the only thing that can be said strongly is that shared
    linking of system libraries makes the program more robust. If, for
    instance, a system call is changed down in the bowels of the system, a
    shared libc link will continue to work on the new release whereas a
    program statically linked with libc cannot.

    AS

  3. Re: portability: static vs. shared?

    Jean-Rene David wrote:
    > Would anyone care to explain *why* statically linking
    > libraries might make programs less portable than linking
    > dynamically?


    And just to be precise, this is not about _portability_ (which is a
    source concept) per se. Rather, it's about the ability of a linked
    binary to continue to work on different physical systems of the same
    type, on different distributions (in the case of Linux), and when the
    underlying OS is patched or upgraded or reconfigured.

    AS

  4. Re: portability: static vs. shared?

    On Nov 1, 2:45*pm, Jean-Rene David wrote:
    > Hello,
    >
    > My naive common sense and a few authors[1] say that linking
    > libraries statically makes program binaries more portable.
    >


    Well I don't know about portability. But I replaced my vendor
    supplied apache package, which used dynamically linked modules, with a
    homegrown apache intstalled into /usr/local, all modules statically
    linked, and the startup time went from 10+ seconds (mod_perl) to less
    than 2 seconds. I like speed.

    --
    Webmail for Dialup Users
    http://www.isp2dial.com/freeaccounts.html


  5. Re: portability: static vs. shared?

    On Nov 1, 3:45 pm, Jean-Rene David wrote:

    > My naive common sense and a few authors[1] say that linking
    > libraries statically makes program binaries more portable.


    > However I have seen it written here on c.u.p[2] that static
    > linking a makes programs *less* portable.


    > Would anyone care to explain *why* statically linking
    > libraries might make programs less portable than linking
    > dynamically?


    It depends on which libraries. For system level libraries, you
    should definitely link dynamically; the actual hardware level
    code which implements something like read may vary from one
    version to the next (or even from one system to the next), but
    the interface to read won't. For other things, it depends; if
    you link statically, you know what you're getting, but you may
    be restricted if what you are getting doesn't work on a specific
    machine.

    --
    James Kanze (GABI Software) email:james.kanze@gmail.com
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

  6. Re: portability: static vs. shared?

    John Kelly writes:
    > On Nov 1, 2:45*pm, Jean-Rene David wrote:
    >> Hello,
    >> My naive common sense and a few authors[1] say that linking
    >> libraries statically makes program binaries more portable.

    >
    > Well I don't know about portability. But I replaced my vendor
    > supplied apache package, which used dynamically linked modules, with a
    > homegrown apache intstalled into /usr/local, all modules statically
    > linked, and the startup time went from 10+ seconds (mod_perl) to less
    > than 2 seconds. I like speed.


    It's not only startup time. A call to a routine in a dynamically
    linked ELF shared object will usually be translated as a 'call' to a
    trampoline in the PLT (procedure linkage table), which does an
    indirect jump to an address loaded from a particular slot in the GOT
    (global offset table). When the first call to something happens, this
    sequence ends up in the dynamic linker, which loads (if necessary)
    the corresponding file and changes the address in the GOT to be the
    real entry point of the routine which was supposed to be called. This
    implies that all invocations of such a routine are actually indirect,
    which is (of course) slower than just transfering control to an
    address often encoded as part of the transfer instruction itself.

    Basically, dynamic linking is a space-speed tradeoff, where speed is
    reduced in order to save space. That's usually sensible, because the
    amount of available space is finite, while the amount of available CPU
    time is not (at least not because of technical reasons). It's also
    good for extensible languages (like Perl), because without dynamic
    loading, each set of extensions used together would require a perl
    executable of its own (or each extension supposed to be used would
    need to be compiled into 'the perl executable').

+ Reply to Thread