From owner-cvs-all@FreeBSD.ORG Fri Aug 24 21:44:34 2007 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A23516A46B; Fri, 24 Aug 2007 21:44:34 +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 3167B13C467; Fri, 24 Aug 2007 21:44:32 +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 l7OLiUss010934; Sat, 25 Aug 2007 01:44:30 +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 l7OLiUhC010933; Sat, 25 Aug 2007 01:44:30 +0400 (MSD) (envelope-from yar) Date: Sat, 25 Aug 2007 01:44:29 +0400 From: Yar Tikhiy To: Daniel Eischen Message-ID: <20070824214429.GB99474@comp.chem.msu.su> References: <200708230509.l7N59VCi048341@repoman.freebsd.org> <20070824183630.GA99474@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/lib/libc/gen fts-compat.c fts-compat.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2007 21:44:34 -0000 On Fri, Aug 24, 2007 at 03:14:53PM -0400, Daniel Eischen wrote: > On Fri, 24 Aug 2007, Yar Tikhiy wrote: > > >On Fri, Aug 24, 2007 at 11:03:12AM -0400, Daniel Eischen wrote: > >>On Thu, 23 Aug 2007, Yar Tikhiy wrote: > >> > >>>yar 2007-08-23 05:09:31 UTC > >>> > >>>FreeBSD src repository > >>> > >>>Modified files: > >>> lib/libc/gen fts-compat.c fts-compat.h > >>>Log: > >>>Forced commit to note repo-copy: > >>> > >>>These files have been repo-copied from src/include/fts.h > >>>and src/lib/libc/gen/fts.c to serve as a base for 4.4BSD > >>>compatible versions of fts(3) functions to be preserved > >>>through libc symbol versioning while the default versions > >>>undergo ABI-breaking extension to support big file trees. > >> > >>When are you going to break the ABI? After 7.0 is tagged > >>and released? If you break the ABI before, you don't need > >>or want to have the compat versions; the libraries have already > >>been bumped in prep for release. I don't think we want to > >>use symbol versioning as a crutch for -current users; the > >>version definitions are meant for public releases only. > > > >The reason for exercising symbol versions right now is that "make > >installworld" is sensitive to the fts(3) ABI. If the ABI is just > >broken w/o special measures, "make installworld" will fail in the > >middle and leave you with a botched system. It goes as follows: > > > >- "make installworld" copies the old /usr/bin/find and some other > > tools to /tmp/install.xxx for use during the install > >- libc is overwritten by its new instance, with new fts(3) ABI > >- the old find(1) is run by installworld and dumps core immediately. > > Why don't you make find and the install tools static. They are just copied from /usr/bin and friends before the actual install process starts. I had the idea of using newly built tools with LD_LIBRARY_PATH set to ${WORLDTMP}/{lib,usr/lib} for that purpose, but its discussion with ru@ didn't end up in a definite conclusion whether it was feasible. I haven't had time to experiment with my idea yet. > >Earlier the problem was to be avoided by bumping libc version so > >that the old libc is kept, and now I chose symbol versioning to get > >around it. Do you think there is a different way? > > Yes, you wait until after release to do this. Look at it Excuse me, but I don't want to have the bug I'm trying to fix (bin/104458) in 7.0-RELEASE. I'm certain we'll work out a way to have the bug fixed, with or without symbol versioning. > this way: if there wasn't symbol versioning and libc was > already bumped, how would you solve the problem? You > wouldn't bump libc again, right? I've believed that symbol versioning should help us to fix bugs, not prevent us from doing so. Not having to bump the libc version each time was the main reason to have symbol versioning, wasn't it? -- Yar