From owner-cvs-src@FreeBSD.ORG Wed Aug 29 07:30:38 2007 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8423616A41B; Wed, 29 Aug 2007 07:30:38 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id A891E13C442; Wed, 29 Aug 2007 07:30:36 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.4) with ESMTP id l7T7UEuo022911; Wed, 29 Aug 2007 11:30:14 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.4/Submit) id l7T7UBAO022909; Wed, 29 Aug 2007 11:30:11 +0400 (MSD) (envelope-from yar) Date: Wed, 29 Aug 2007 11:30:11 +0400 From: Yar Tikhiy To: Daniel Eischen Message-ID: <20070829073011.GD598@comp.chem.msu.su> References: <200708270850.20904.jhb@freebsd.org> <200708281142.07941.jhb@freebsd.org> <200708281403.05931.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Cc: src-committers@freebsd.org, John Baldwin , peterjeremy@optushome.com.au, alfred@freebsd.org, cvs-all@freebsd.org, cvs-src@freebsd.org, "M. Warner Losh" Subject: Re: cvs commit: src/lib/libc/gen fts-compat.c fts-compat.h X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2007 07:30:38 -0000 On Tue, Aug 28, 2007 at 04:15:16PM -0400, Daniel Eischen wrote: > On Tue, 28 Aug 2007, John Baldwin wrote: > > >On Tuesday 28 August 2007 01:18:38 pm Daniel Eischen wrote: > >> > >>The only thing I would add is that we can do this by using the > >>real public versions in -current instead of private ones only > >>seen in current. By using the public versions, -current users > >>will never have to rebuild any of their ports _unless_ the > >>same ABI changed more than once in -current, and that has > >>never happened in the past. If it does happen, you can > >>remove interim versions from RELENG_X at the branch, and > >>then remove the interim version from -current some time later. > >>This is the same approach as using a "private in current" > >>version namespace. The only disadvantage is that you might > >>be missing a version or two in RELENG_X if you remove an > >>interim FBSD_1.4 for instance. > > > >Yes, but how do you know which ones are interim versions that are safe to > >be > >removed? Having separate namespaces makes this clear. > > Any symbol in the Symbol.map files (or the generated Version.map) > that is duplicated from the point at which -current was last > branched. > > If you go with my approach and only create one new version in > -current, then it will be more obvious because the symbol(s) > will already exist in -current's one and only version. That > will force us to decide whether we should force a rebuild or > just make a new version - it could be on a case by case basis > if it ever happened. > > But even with the other approach (each ABI change creates a > new version), you could write a script to find all the versions > with duplicate symbols. I suppose you could even have it > generate an ObsoleteVersions file that gets committed along > with the most recent ABI change. At this point we should consider technical limitations as well. I think I found a couple, unfortunately. On the one hand, John's approach depends on alias symbols in HEAD so, e.g., both foo@FBSD-1.9 (public) and foo@FBSD-current-1.8.5 (interim) can point to the same implementation for the "foo" interface after STABLE with foo@FBSD-1.9 was branched. However, the GNU build tools don't seem to provide a straight way to that, they return an error if multiple versions reference the same function, so more stub code will be needed in the library, which will add to complexity of the approach. On the other hand, Symbol.map files should not contain duplicate symbol names as it seems to violate ld(1) semantics. Therefore, if following Daniel's way, we'll need to track which symbols moved by more than one version since the last STABLE branch to find interim versions. This shouldn't be too hard, but the implementation details are somewhat different. -- Yar