On Wed, 12 May 2010, Rob Landley wrote: > Ulrich Drepper, the glibc maintainer, has gone crazy and believes that You mean he wasn't already? ;)
> static linking should never be used for anything: > > http://people.redhat.com/drepper/no_static_linking.html That's ironic, considering that one of *my* annoyances last I dealt with glibc, was that it would not honour --disable-static. Since I had no use for debug or profile, this doubled my compilation time. In fairness to him, though, he lives in a different world. Glibc has maximal backwards compatiblity, so a shared build against an early glibc version is nearly as good as static (within the glibc fold...). > (Somebody should tell him about execute in place support, about dynamic > linking dirtying per-process physical pages, These are characteristics of ELF, not shared libraries in general. It's quite possible to have a form of shared libraries that still uses absolute linking. You just have to agree in advance on what address space belongs to the librar(ies) and to the executable. A jumptable is still needed if you want freedom to recompile the shared library without recompiling dependent executables. But if you're building an immutable system, you could even dispense with that. (This would be like oldschool overlays, with the "library" being an executable that passes control to "executables" that are really overlays against itself.) Alternative approaches are not nearly as convienient to program for as standard ELF. Linux originally used a system like this (libc.so.4 / a.out), but this was abandoned for good reason. Nonetheless, its important to remember that "bloated static" and "full blown dynamic linking" are not the only possibilities. ---- Michael Deutschmann <[email protected]> _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
