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

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

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

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

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').