From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu From: Christoph Hellwig Message-ID: <20040422173022.GA28499@lst.de> Content-Type: text/plain; charset=us-ascii References: <086a01c4272b$dc362730$0fca7d50@SOMA>, Subject: Re: [9fans] acme, rio workalike available in plan 9 ports Date: Fri, 23 Apr 2004 08:55:07 +0000 Topicbox-Message-UUID: 699a1b1a-eacd-11e9-9e20-41e7f4b1d025 On Wed, Apr 21, 2004 at 12:19:47AM +0000, ron minnich wrote: > On Wed, 21 Apr 2004, boyd, rounin wrote: > > > > how long does it take to recompile the entire system if you have a bug in > > printf? > > wrong question. On many of these later systems, as I said, app .o is tied > to lib .so. So it doesn't matter if you just rebuild the library -- the > app may not be fixed because it is tied to (e.g.) GLIBC 2.0 versioned > symbols, and the fixed symbols are later versions. So you replace a broken > libc.so with a new one, and guess what? not all your apps are fixed. You > have to replace the apps anyway, so they'll use the right symbols. Your statement doesn't make a lot of sense. The symbol version is incremented when the interface changes, e.g. FILE grows or off_t or what the heck. It's not incremented when the implementation changes. And when you look over glibs you'll the symbols with older versions are usually wrappers around the current version. And even if not you can be sure the maintainers will fix all versions if it's possible without changing the interface. 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.