I finally got everything to compile and link, but I could not make it work with static. I had to use --enabled-shared. Why would anybody prefer shared over static

I must be missing something here.

Yes:

#!/usr/bin/perl
use v5.12;
use warnings;

my $n=0;
my $bytes=0;
for my $dirname (split /:/,$ENV{'PATH'}) {
        opendir my $dir,$dirname or die "Can't open $dirname: $!";
        my @exe=grep { -f -x $_ } map { "$dirname/$_" } readdir $dir;
        closedir $dir;
        say "$dirname: ",0+@exe;
        $n+=@exe;
        $bytes+=-s $_ for @exe;
}
say "total: $n, $bytes";
[download]

On my Slackware server, I count 3780 executables, most of them dynamically linked, using 765_220_787 bytes.

Imagine a bug in a common library, like libc.so. How do you fix it?

On a dynamically linked system, replace the broken libc.so and reboot. ld.so will link the repaired libc.so into all dynamically linked executables. Problem solved, replacing one file of about 2 MBytes in size. (We could discuss if rebooting is really needed or going through single user mode is sufficient, but a reboot eleminates all traces of the broken library in memory.)

On a statically linked system, ALL executables linked against the broken library have to be replaced. In case of libc, that means all executables, except for one or two specially crafted executables that work without libc, and except for scripts. On my server, that would be about 2500 to 3000 executables (estimating most of the 3780 executables are binaries), using most of the 700+ MBytes.

I prefer downloading 2 MBytes to fix a bug in a single place over downloading 700 MBytes and scanning each and every executable to see if it was linked against a broken static library.

Also, the code of shared libraries is (ideally) kept in memory only once, whereas statically linked executables don't share identical code, wasting memory that could be used for other purposes (filesystem caching, application data).

See also https://en.wikipedia.org/wiki/Library_%28computing%29

Alexander