From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig To: 9fans@cse.psu.edu Subject: Re: [9fans] acme, rio workalike available in plan 9 ports Message-ID: <20040423164750.GB23473@lst.de> References: <20040423152948.GA23473@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i Date: Fri, 23 Apr 2004 11:47:50 -0500 Topicbox-Message-UUID: 6b7147d8-eacd-11e9-9e20-41e7f4b1d025 On Fri, Apr 23, 2004 at 03:56:03PM +0000, ron minnich wrote: > I think unless I'm wrong that you've actually demonstrated the problem I'm > trying to show -- an old binary, using a broken interface, doesn't get > fixed just because you update the library. What happens is that the old > binary retains the broken interface. This is not what people think of with > shared libraries -- they naively think you upgrade the library and good > things happen, bugs are fixed, angels sing. glibc retains old broken > interfaces as time moves forward -- is this really a good idea? I think this depends on your defintion of broken. E.g. if FILE grows to support $RANDOM new feature is the old interface broken because of that? If I had a third party program on my system that I don't have sources for I'd be more than happy to keep that supported, yes. I think I understand your point, but it looks more like a thoeretical issue than something that comes up in practice. Yes, symbol versioning does allow you to keep the old version around, as do weak symbols if you overrode it in your program, etc.. The thing is that the way it's used in practice works different. > In other words, shared libraries certainly solve a problem, but I'm not > sure any more which one it is. They still allow you to fix problems in a central place. Just because you might have two versions of the same symbol that doesn't mean you're magically unable to fix them.