Why Static D1135249771 Auriel (82.182.149.46) #Why has Plan 9 chosen statically linked binaries instead of dynamic #ones? Read below: # #[http://groups.google.com/group/comp.os.plan9/msg/42c4232fac260f29] #! From: rminn...@lanl.gov (ron minnich) #! Subject: Re: [9fans] acme, rio workalike available in plan 9 ports #! Message-ID: #! Date: Tue, 20 Apr 2004 14:57:50 GMT #! #! On Tue, 20 Apr 2004, boyd, rounin wrote: #! #! > debian managed to shoot themselves in the foot with some libc, #! > some time back. you couldn't go forward 'cos other stuff would #! > break and you couldn't go back 'cos more stuff would break. #! #! gets better. Symbols are now versioned (well, this really happened a few #! years back). So you are very tightly screwed (good word) to the library #! you use, and it covers a definite range forward/backward. I assume but am #! not sure that glibc nowadays encompaesses lots of versions of lots of #! functions going back for years. Which also means the version naming of the #! file (libc-2.3.2.so) has a lot less meaning than it used to. At some #! point, given the tight wiring of an executable to the particular library #! version, one starts to lose track of just why .so's are still thought to #! be a good idea (I mean, on a 1960s-era Burroughs machine with not much #! memory, I get it, but ... /bin/cat on my Redhat box at 20K, is not much #! smaller than /bin/cat on Plan 9 (22K stripped), and the Plan 9 one doesn't #! do symbol fixup every time it runs ...). #! #! And, as Linus mentioned, TLBs matter. Hmm. Judging by 'ps', cat on linux #! needs 256 of them, and cat on Plan 9 needs 6. xclock has got 900 or so, #! and Plan 9 clock appears to have 3*30 or so (3 clock procs when you run #! clock). #! #! So you do pay a bit for .so's. You don't gain an #! implementation-independent interface for your programs, since the .so is #! versioned and the symbols in it are versioned; I wonder what you DO gain? #! The theory always was you could swap out a shared library and swap in a #! bug-fixed version, which sounds nice until you try it and it fails #! miserably (there was a time when this worked ...) #! #! ron # #! From: Ron Minnich #! To: 9fans #! #! On Fri, 23 Apr 2004, Christoph Hellwig wrote: #! #! > That beeing said I'm the last one to defend glibc's bloat, but in a #! > system where you can't easily rebuild all binaries for whatever #! > reason shared libraries and symbol versioning makes a lot of sense. #! #! No, it doesn't help much at all. #! #! Let's take program 'a', which depends on stat. In the new order of gcc, #! when built, 'a' will depend on stat from glib 2.0. A new stat comes along #! with fixes. It gets built into glibc 2.1. You install glibc 2.1. Program #! 'a', unless I rebuild or replace it, will be using the old stat. Of #! course, I might think that the shared library has fixed all binaries using #! stat, and I'm wrong -- or am I right? Is the V1 stat just a wrapper? who #! knows? And do you cover all the cases? And maybe it isn't calling stat and #! I don't know it. Maybe it's calling one of these: #! #! 000c888c t __GI___fxstat #! 000c90cc t __GI___fxstat64 #! 000c90cc t ___fxstat64 #! 000c888c T __fxstat #! 000c90cc T __fxstat64@@GLIBC_2.2 #! 000c90cc T__fxstat64@GLIBC_2.1 #! 000c90cc t __old__fxstat64 #! 000c888c t _fxstat #! #! I've found programs that call all these variants, because the functions #! they call call different library functions. It's quite interesting to see. #! Which one is 'a' calling? Oh yeah, you can max out the ld.so debug #! options, because of course weak symbols come into this game too, and #! you're not really sure unless you watch this: #! #! 19595: binding file /lib/libpthread.so.0 to /lib/libc.so.6: #! normal symbol `getrlimit' [GLIBC_2.2] #! 19595: symbol=__getpagesize; lookup in file=date #! 19595: symbol=__getpagesize; lookup in file=/lib/libpthread.so.0 #! 19595: symbol=__getpagesize; lookup in file=/lib/librt.so.1 #! 19595: symbol=__getpagesize; lookup in file=/lib/libc.so.6 #! #! yup, several hundred lines of this stuff, for 'date'. Of course it's kind #! of interesting: Posix threads are used by 'date'. I had no idea that #! printing a date could be so complex. Maybe that's why it's 40k -- bigger #! than some OSes. #! #! The symbol versioning breaks assumptions users have about how shared #! libaries work -- that they provide a link to one version of a function and #! if you replace the library all the programs get fixed. I've seen this #! problem in practice, for both naive users and very non-naive sysadmins. #! #! The symbol versioning wires programs to something beyond a library #! version, in a way that is not obvious to most people. To fix a binary that #! uses a library, you have to replace the binary, not just the library, or #! you can not be sure anything gets fixed. #! #! That said, if you can't rebuild all the binaries, well then you're stuck, #! and have no idea if your new shared library is going to fix anything at #! all for some of those binaries. Some will stay broken, since replacing the #! library did not necessarily replace broken functions -- the new library #! has them too, for backwards compatibility. So the upgrade is not an #! upgrade. This is a feature? #! #! ron #