tag:blogger.com,1999:blog-5968355124473522212.post3742929176362961589..comments2024-01-03T23:03:57.300+02:00Comments on Nibble Stew: Is static linking the solution to all of our problems?Jussihttp://www.blogger.com/profile/03370287682352908292noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-5968355124473522212.post-85899585294525637432017-04-05T19:17:06.460+03:002017-04-05T19:17:06.460+03:00Unfortunately this blog post is just making assump...Unfortunately this blog post is just making assumptions without any empirical evidence. Glibc does not work well with static linking. A better starting point would be a distro that uses 'Musl' by default, for instance 'Alpine Linux'. You still need to recompile stuff, but it's easier with the native libc.<br /><br />I agree that having everything linked statically system wide is a bad idea, but it might be worth the trouble for some small set of applications. For example my 'busybox' & utility initramfs image is 95% smaller when compiled and linked statically against musl (compared to glibc). Haskell and Rust programs apparently become significantly smaller when (statically) linked with musl. I benchmarked hundreds of concurrent shell+screen+irssi sessions on a vps environment, simulating a irc shell server. The memory footprint of the statically linked software (musl+screen+dash+irssi) was 50% lower, 8 vs 16 GB (vs glibc+screen+bash+irssi). Overall, the size difference between dynamic/static libc is much smaller when using musl, which appaears to be designed for static linking unlike glibc.miasmahttps://www.blogger.com/profile/12710096873877267938noreply@blogger.comtag:blogger.com,1999:blog-5968355124473522212.post-32905205313157481612017-03-18T20:25:31.189+02:002017-03-18T20:25:31.189+02:00I was wondering about this, too. Tried to compile ...I was wondering about this, too. Tried to compile a couple of random programs from /usr/bin as static, turned out that it's far more difficult than expected. Either dh_configure eats the static flag, there are dependencies missing that are handled by dynamic linker or something else... and looks like it's different for each package.Kuhankeittäjähttps://www.blogger.com/profile/14440179726891692524noreply@blogger.comtag:blogger.com,1999:blog-5968355124473522212.post-60431879474004423762017-03-17T10:14:50.429+02:002017-03-17T10:14:50.429+02:00Quoting myself from the article above in case you ...Quoting myself from the article above in case you did not read all of it before commenting:<br /><br />A counterargument people often make is that static linking is more efficient than dynamic linking because the linker can throw away those parts of dependencies that are not used. If we assume that the linker did this perfectly, executables would need to use only 5% of the code in their dependencies for static linking to take less space than dynamic linking. This seems unlikely to be the case in practice.Jussihttps://www.blogger.com/profile/03370287682352908292noreply@blogger.comtag:blogger.com,1999:blog-5968355124473522212.post-80570534715657604382017-03-17T10:06:59.209+02:002017-03-17T10:06:59.209+02:00In many languages the standard library is provided...In many languages the standard library is provided as a shared library but everything else is statically linked. I removed stdlibs in this measurement to mimic that behaviour.Jussihttps://www.blogger.com/profile/03370287682352908292noreply@blogger.comtag:blogger.com,1999:blog-5968355124473522212.post-299492943149771172017-03-17T10:02:45.999+02:002017-03-17T10:02:45.999+02:00You say your scenario does not allow dynamic linki...You say your scenario does not allow dynamic linking, but then you subtract the size of language stdlibs. But why is that possible, if they're not dynamically linked? What other mechanism does the language use to make those symbols available in this scenario?djbhttps://www.blogger.com/profile/13206790143698555345noreply@blogger.comtag:blogger.com,1999:blog-5968355124473522212.post-29305287793893596732017-03-17T09:25:01.875+02:002017-03-17T09:25:01.875+02:00Sinun blogi on Suomeksi :)Sinun blogi on Suomeksi :)zeenixhttps://www.blogger.com/profile/04142631863736897222noreply@blogger.comtag:blogger.com,1999:blog-5968355124473522212.post-65017613186838608882017-03-17T02:13:46.414+02:002017-03-17T02:13:46.414+02:00Don't forget the bandwidth difference when an ...Don't forget the bandwidth difference when an openssl or libc upgrade means you have to redownload every binary that ever linked against such a core library... Static linking is great for Google's internal systems, with several tens of thousands of machines just dedicated to recompiling code and 10Gbps ethernet to every box... not so much for normal humans!James Brownhttps://www.blogger.com/profile/03689879611011141899noreply@blogger.comtag:blogger.com,1999:blog-5968355124473522212.post-48818140081711594042017-03-17T00:27:47.979+02:002017-03-17T00:27:47.979+02:00There's a flaw in your methodology: statically...There's a flaw in your methodology: statically linking a library drops any object that isn't actually used. For a simple example, consider a program linked against libc.so.6 and uses only, say, gettimeofday() ; now link it against the static libc, it will not grow by the (massive) size of the libc, but by the size of the .o that contains the gettimeofday function (plus the size of the .o that contain the functions it uses). In the case of gettimeofday, it would be gettimeofday.o, localtime.o, tzset.o and lowlevellock.o, if I'm not mistaken.glandiumhttps://www.blogger.com/profile/00111150844502160018noreply@blogger.com