From owner-cvs-src@FreeBSD.ORG Thu May 8 18:45:48 2008 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 260DC1065672 for ; Thu, 8 May 2008 18:45:48 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.234]) by mx1.freebsd.org (Postfix) with ESMTP id CC56C8FC13 for ; Thu, 8 May 2008 18:45:47 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: by wr-out-0506.google.com with SMTP id 50so426598wra.13 for ; Thu, 08 May 2008 11:45:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer:mime-version:content-type; bh=OoMlb72S8yxDFQcrEUSuAzXUu4idhRGtuJXIBqeGvB4=; b=iatHMHH/VKX5DAivkcuzAeehx34YFV52X9CBvb5GlifHpKi/+B5HnBs4ZKZWFpvfVxww1tVL6u0uDjj8icBnmYPYUPxcgN3L23oKKdmEbL0Xl+CzS/tFZxaTV3jVXePmuS4BI4tSNND1Vudt8xb3yhOBinkOMcBxWBbBxO9TsSI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer:mime-version:content-type; b=l5MkNbycirUWF8RaX9xJq8cFbMFxdvD1bV0OyQ9o2RFfvppcJYdwrXjAjix02vmuDQrHCLJE0PF1lqzuerNS8ydJqR6p+fG5olD4t6ilqPicCDjEj3NyhgIxpHWdp9gMaop5aqX9UruNUXbH3nWldK+fIV+m5/oXZuqSuWXRsa8= Received: by 10.100.12.1 with SMTP id 1mr4848792anl.22.1210272346976; Thu, 08 May 2008 11:45:46 -0700 (PDT) Received: from kan.dnsalias.net ( [24.218.183.247]) by mx.google.com with ESMTPS id c16sm5221876anc.31.2008.05.08.11.45.41 (version=SSLv3 cipher=RC4-MD5); Thu, 08 May 2008 11:45:42 -0700 (PDT) Date: Thu, 8 May 2008 14:45:36 -0400 From: Alexander Kabaev To: Daniel Eischen Message-ID: <20080508144536.55a1a1d1@kan.dnsalias.net> In-Reply-To: References: <200805071539.m47FdYWZ033147@repoman.freebsd.org> <48224C59.7090005@FreeBSD.org> X-Mailer: Claws Mail 3.4.0 (GTK+ 2.12.9; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/Ceq9E81JbXZ9IiyfFnSVliC"; protocol="application/pgp-signature"; micalg=PGP-SHA1 Cc: Alexander Kabaev , cvs-src@freebsd.org, src-committers@freebsd.org, Jason Evans , cvs-all@freebsd.org Subject: Re: cvs commit: src/lib/libc Versions.def 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: Thu, 08 May 2008 18:45:48 -0000 --Sig_/Ceq9E81JbXZ9IiyfFnSVliC Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Thu, 8 May 2008 01:55:32 -0400 (EDT) Daniel Eischen wrote: > On Wed, 7 May 2008, Jason Evans wrote: >=20 > > Alexander Kabaev wrote: > >> kan 2008-05-07 15:39:34 UTC > >> > >> FreeBSD src repository > >> > >> Modified files: > >> lib/libc Versions.def Log: > >> Keep versions on a dependency chain to exclude even remote > >> possiblity of private version ever getting index 2. > > > > Why is this the right thing to do? Clearly FBSDprivate_1.0 should > > never be incremented, but it does not make sense to me to have it > > depend on any other version. In the absence of a compelling > > argument, I am of the opinion that Dan Eischen made a good change. > > Did you discuss this issue with him? >=20 > I think it has more to do with how rtld works, though I don't > know the details. You can see that kan made this same exact > change in rev 1.3 of Versions.def. So in actuality, I backed > kan's change out thinking that I had originally committed it > that way. > --=20 > DE rtld magically expects version with verndx 2 to be the oldest version applied to the shared library. It uses this to resolve symbols for old unversioned binaries that happen to run against the versioned library. Having FBSDPrivate to be a root of its own depenency tree can potentionally cause linker to assign it version #2 instead of FBSD_1.0, breaking old binaries. Keeping all versions in a dependency chain rooted at FBSD_1.0 is a simple way to avoid the breakage. In general, 'dependency' in version strings is useless and people should read too much into it. Nor should they apply their object-oriented language concepts while looking at what version inherits from what other version. >=20 > FYI, before I commited this change, I looked at how glibc did it. > Their private namespace does not inherit from the GLIBC public > namespace. But perhaps they have other ways of preventing > exactly what kan is trying to avoid. >=20 You looked at sources, I guess, not what gets generated after they run their AWK script on it. $ readelf -V /compat/linux/lib/libc-2.3.6.so ... Version definition section '.gnu.version_d' contains 18 entries: Addr: 0x0000000000011b40 Offset: 0x011b40 Link: 4 (.dynstr) 000000: Rev: 1 Flags: BASE Index: 1 Cnt: 1 Name: libc.so.6 0x001c: Rev: 1 Flags: none Index: 2 Cnt: 1 Name: GLIBC_2.0 0x0038: Rev: 1 Flags: none Index: 3 Cnt: 2 Name: GLIBC_2.1 0x0054: Parent 1: GLIBC_2.0 ... 0x0230: Rev: 1 Flags: none Index: 17 Cnt: 2 Name: GLIBC_PRIVATE 0x024c: Parent 1: GLIBC_2.3.4 --=20 Alexander Kabaev --Sig_/Ceq9E81JbXZ9IiyfFnSVliC Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFII0pQQ6z1jMm+XZYRAvtYAKCvPeRD/2wFAd+z2v1ZWIyQYhuNGwCg1b8V 1isYh6ME9yxTUStxNTwqR98= =gGg0 -----END PGP SIGNATURE----- --Sig_/Ceq9E81JbXZ9IiyfFnSVliC--