For information on editing, see the description of Plan 9 wiki syntax.
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: <Pine.LNX.4.44.0404200840490.13657-100000@maxroach.lanl.gov> ! 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
