From owner-freebsd-current@FreeBSD.ORG Sun Apr 11 19:20:56 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D642106564A; Sun, 11 Apr 2010 19:20:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 9FC878FC17; Sun, 11 Apr 2010 19:20:55 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o3BJKnbK008864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Apr 2010 22:20:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o3BJKnYo081498; Sun, 11 Apr 2010 22:20:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o3BJKnRb081497; Sun, 11 Apr 2010 22:20:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 11 Apr 2010 22:20:49 +0300 From: Kostik Belousov To: Julian Elischer Message-ID: <20100411192049.GX2415@deviant.kiev.zoral.com.ua> References: <4BC03ABA.6090309@elischer.org> <4BC0CC6F.7010009@freebsd.org> <4BC0E9AE.1000904@elischer.org> <4BC0FF80.4000907@freebsd.org> <20100411102723.GT2415@deviant.kiev.zoral.com.ua> <4BC213A5.4020104@elischer.org> <20100411184406.GV2415@deviant.kiev.zoral.com.ua> <4BC21F48.8090407@elischer.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RTy+eQJHeE7YIlEm" Content-Disposition: inline In-Reply-To: <4BC21F48.8090407@elischer.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_05, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: ports@freebsd.org, FreeBSD Current Subject: Re: ports and PBIs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2010 19:20:56 -0000 --RTy+eQJHeE7YIlEm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 11, 2010 at 12:13:12PM -0700, Julian Elischer wrote: > On 4/11/10 11:44 AM, Kostik Belousov wrote: > >On Sun, Apr 11, 2010 at 11:23:33AM -0700, Julian Elischer wrote: > >>On 4/11/10 3:27 AM, Kostik Belousov wrote: > >> > >>>I already pointed in the other reply in this thread, $ORIGIN dynamic > >>>token should solve the issue. See > >>>http://docs.sun.com/app/docs/doc/817-1984/chapter3-13312?l=3Den&a=3Dvi= ew > >> > >>yes, teh question I have since I am not alinker expert is do we > >>support it? the link you give is for Solaris I think.. > > > >It is in three for HEAD, RELENG_8 and RELENG_7. >=20 >=20 > thank you. >=20 > This will I think as you suggest, make a significant difference. >=20 > the question I have is "is it re-evaluated for each library"? I am not sure what exactly you are asking there. $ORIGIN is substituted for each object invividually, taking the object path as a substitution target. That is, if main executable A references dso $ORIGIN/X/libA.so, then libA.so is looked up in the subdirectory X of directory containing A. If libA.so references $ORIGIN/Y/libB.so, then libB.so is looked up in X/Y subdirectory of directory containing A. >=20 > So, to recap: >=20 > what we were thinking is something along the lines of the following: >=20 >=20 > an example with 2 PBI apps created at the same time > (part of the same set) >=20 > application 1 --------> libraryA - - (originally) - - ->library B > | / | > |link / |link > | /-----------(y)-------/ | > v / v > common area dd-mm-yy library A ------(x)------------>library B > ^ ^ > |link |link > | | > | | > application 1 --------> libraryA - - (originally) - - - ->library B >=20 > library A and B in app 2 are deleted >=20 > the idea that all the PBIs developed as part of a release set > (labeled as set dd-mm-yy in this example, would > have identical libraries in them and would thus be candidates for > "library consolidation". > The question is and I guess it's not really that important, whether > satisfaying a dependency in library A due to application 1 will use=20 > path (x) or path (y). >=20 > certainly we would need to label the versions of the libraries in the > common area with a hash or something, or maybe some other unique > label. (port sequence number plus build args?) so that we don't > use a copy of the library that is not really suitable for that app. >=20 > A really top class effort would be ab;e to know hte set of build > options on a library that would make the outcome "acceptable". > but I doubt that we want to go that far. >=20 > if a person takes PBIS from set "01-01-2011" hey will tend to find > common libraries. butit for some reason they need to take something > from set "01-01-2009" (i.e. an old PBI, for some compatibility reason) > it is guaranteed to work, despite the fact that there may well be > collisions between library versions, because it will not be linked > with those in the common area that do not match and will instead be > linked with its own copies. >=20 >=20 > Julian --RTy+eQJHeE7YIlEm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkvCIRAACgkQC3+MBN1Mb4iWaQCfS7l+5Uy5yAwZvJEsCsQndiMx eKkAoMg8NQiiMUkuSgPEgTR1HscvRP68 =QbxQ -----END PGP SIGNATURE----- --RTy+eQJHeE7YIlEm--