On 26 Apr 2012, at 12:38, Bob Bishop wrote: > Hi, > > On 26 Apr 2012, at 10:35, Konstantin Belousov wrote: > >> I think it is time to stop building the toolchain static. I was told that >> original reasoning for static linking was the fear of loosing the ability >> to recompile if some problem appears with rtld and any required dynamic >> library. Apparently, current dependencies are much more spread, e.g. /bin/sh >> is dynamically linked [etc] > > That seems like a bad mistake, because it would prevent even booting > single-user if rtld/libraries are broken.
That's what /rescue is for. You will find statically linked tools there that are just about to repair a broken system (a static nc would also be nice...). I did some benchmarks a little while ago, and there was, I think, about a 5% slowdown on buildworld with a dynamically linked clang vs a statically linked one on x86-64. Ideally, I'd want the bootstrap compiler to be statically linked but the installed one to be dynamic. The advantage of dynamic linking is small now, but as we add more LLVM and clang-based tools to the base system (e.g. LLVM-based firewall JIT, clang-based indent replacement) we're going to see lots of simple tools being 5-10MB if we enforce static linking. We'll probably get a much bigger speed win from clangd (hopefully appearing in time for LLVM 3.2) avoiding the need to spawn a new process for every compiler invocation than we'll save from static linking. As to compiling things when rtld is broken... clang in the base system currently dynamically links to lib[std]c++, libgcc_s, libm and libc, it only statically links to the clang and LLVM libraries. David_______________________________________________ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
