mb@aldous ~ $ ldd /usr/bin/perl5.14.2
        linux-vdso.so.1 =>  (0x00007fff5677e000)
        libperl.so.5.14 => /usr/lib64/libperl.so.5.14 (0x00007f62b38ff
+000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f62b356d000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f62b3369000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f62b30e5000)
        libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f62b2eae000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f62b2c91000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f62b3c81000)
[download]

I've never bothered to look at how to configure static vs. dynamic compilation but given that both versions exist it must be possible.

I wouldn't worry about it too much though, as another nice feature of virtual memory systems works in your favor: paging. What Linux basically does when loading a binary is just to mark it loaded but paged out to its file. Then when something accesses the image in memory it gets automagically loaded, but in chunks of usually 4 KB, the size of an MMU page. So stuff that's never run is also likely never loaded, unless it has other code that has already been run in its vicinity. It's all pretty damn efficient anyway unless it's C++.

That was my initial thought as well ... meh 1.2M when we live in a much larger world now; however, I started looking at it and while my stock redhat binary is 16K, my own build (perlbrew) is 900K -- the difference being whether libperl (and libresolv) are static or not. It's an interesting build question at a minimum -- like the vendors are not doing default builds.

-derby