From owner-cvs-all@FreeBSD.ORG Tue Sep 4 12:24:04 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 E330D16A41A; Tue, 4 Sep 2007 12:24:04 +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 1CE5B13C46B; Tue, 4 Sep 2007 12:24:03 +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 l84CNxg2089134; Tue, 4 Sep 2007 16:23:59 +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 l84CNwJM089129; Tue, 4 Sep 2007 16:23:58 +0400 (MSD) (envelope-from yar) Date: Tue, 4 Sep 2007 16:23:57 +0400 From: Yar Tikhiy To: Daniel Eischen Message-ID: <20070904122356.GN30502@comp.chem.msu.su> References: <200708270850.20904.jhb@freebsd.org> <200708281142.07941.jhb@freebsd.org> <200708281403.05931.jhb@freebsd.org> <20070829073011.GD598@comp.chem.msu.su> <20070830061935.GF31948@comp.chem.msu.su> <20070904111400.GM30502@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070904111400.GM30502@comp.chem.msu.su> User-Agent: Mutt/1.5.9i Cc: cvs-src@freebsd.org, cvs-all@freebsd.org, src-committers@freebsd.org, "M. Warner Losh" , John Baldwin 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: Tue, 04 Sep 2007 12:24:05 -0000 On Tue, Sep 04, 2007 at 03:14:00PM +0400, Yar Tikhiy wrote: > On Thu, Aug 30, 2007 at 04:38:57AM -0400, Daniel Eischen wrote: > > > > Hmm, I guess it's not that simple. Take a look at the hack I had to make in > > libpthread/thread/thr_private.h (line ~67). I had to create weak references > > to the functions, so for your example, you'd need something like: > > > > __weak_reference(foo0, foo0_10); > > __weak_refefence(foo0, foo0_11); > > __sym_compat(foo, foo0_10, FBSD_1.0); > > __sym_compat(foo, foo0_11, FBSD_1.1); > > > > I think I also needed to make the latest symbol the default, changing > > the last line above to __sym_compat_default(foo, foo0_11, FBSD_1.1), > > but I seem to recall earlier email from you saying this shouldn't > > be needed. I _think_ I needed to for libpthread, but perhaps that > > is because I had the symbols (e.g. foo) listed in both sections of > > the map file: > > > > LIBPTHREAD_1_0 { > > pthread_foo; > > }; > > > > FBSD_1_0 { > > pthread_foo; > > }; > > > > See r.19 of libpthread/pthread.map. > > Just tried this trick, and, alas, it didn't really help. Namely > it helped to make the library buildable, but not all alias versions > of the symbol ended up in it. I tested various combinations of the > __weak_reference, __sym_compat, and __sym_default directives in > conjunction with different symbol maps listing the symbol under one > or many versions. The result was the same: only one alias version > was in the library and available to apps linked against it, while > the other was absent. I must withdraw my argument against alias versions. My problem with them appeared to stem from a typo in "__weak_reference" I'd inherited from your example. :-) It's funny that the compiler emitted just a vague warning: foo.c:12: warning: data definition has no type or storage class foo.c:12: warning: parameter names (without types) in function declaration and the typo remained unnoticed until I saw it by accident. Now I'll investigate if macros can help us to have right versions in branches and HEAD... Do you think there is a non-hackish way to see if we're on a STABLE branch? __FreeBSD_version doesn't seem to provide the information until after the first release from the branch has been cut. OTOH, we should't dump ObsoleteVersions completely because we may need it, too, e.g., when we didn't plan to break an ABI twice in a row but have to. -- Yar