Date: Sun, 11 Apr 2010 22:20:49 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: Julian Elischer <julian@elischer.org> Cc: ports@freebsd.org, FreeBSD Current <current@freebsd.org> Subject: Re: ports and PBIs Message-ID: <20100411192049.GX2415@deviant.kiev.zoral.com.ua> In-Reply-To: <4BC21F48.8090407@elischer.org> References: <x2i7d6fde3d1004100020oc8be3c51ree5f1e4b07b99f45@mail.gmail.com> <4BC03ABA.6090309@elischer.org> <q2q7d6fde3d1004100335ucf424ae0gbfcdba950fd68767@mail.gmail.com> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100411192049.GX2415>