Date: Mon, 12 Apr 2010 13:52:14 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: Julian Elischer <julian@elischer.org> Cc: ports@freebsd.org, FreeBSD Current <current@freebsd.org>, Kris Moore <kris@pcbsd.org> Subject: Re: ports and PBIs Message-ID: <20100412105214.GA2415@deviant.kiev.zoral.com.ua> In-Reply-To: <4BC250D5.7000608@elischer.org> References: <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> <20100411192049.GX2415@deviant.kiev.zoral.com.ua> <4BC250D5.7000608@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--o8+9QDyhj41GtdBs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 11, 2010 at 03:44:37PM -0700, Julian Elischer wrote: > On 4/11/10 12:20 PM, Kostik Belousov wrote: > >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=3D= view > >>>> > >>>>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. > >> > >> > >>thank you. > >> > >>This will I think as you suggest, make a significant difference. > >> > >>the question I have is "is it re-evaluated for each library"? >=20 > You interpreted the question correctly. >=20 > >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 > If there is an LDPATH set then if the library A is to be found > at $SOMEWHERE-ELSE which is in the LDPATH, rather > than in $ORIGIN/X, will it still be found? LD_LIBRARY_PATH ? I do not think this will work, because $ORIGIN substitution (mostly) results in the absolute pathname. It is complicated by the fact that you might do things like ../$ORIGIN/libA.so, but this is plain silly. >=20 > if the answer to the above is yes, then If it is then found > in $SOMEWHERE-ELSE/X somewhere, will it then look for libB.so > in $ORIGIN(A) or in $SOMEWHERE-ELSE ? Regardeless of the answer for the first question, $ORIGIN is evaluated. >=20 > If the library is actually somewhere else (via symlink) is $origin=20 > reevaluated to the actual destination? (that would be cool). No. >=20 >=20 > > > > > >> > >>So, to recap: > >> > >>what we were thinking is something along the lines of the following: > >> > >> > >>an example with 2 PBI apps created at the same time > >>(part of the same set) > >> > >>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 > >> > >>library A and B in app 2 are deleted >=20 > and libraries A and B in "common area" can be updated for security=20 > reasons by a special kind of PBI or package should it be required. >=20 > It sounds to me that link 'y' is followed, i.e. the linker continues > to think it is working in $ORIGIN(A). >=20 > either way this is sounding very doable.. Kris is thinking about a=20 > single sysutils/pbimanager port and a /mk diff that would allow > "make pbi" (once the port was installed). >=20 > I think it actually looks quite feasible. >=20 > Is there someone out there in ports-land who really inderstands the=20 > ports mk framework who could help us (because we'll need a local guide=20 > to make sure we don't dig inn any local burial grounds) and who can=20 > help with testing etc? >=20 > Similarly if we need to do anything funny with regards to hashing=20 > parts of .so files, or deciding how to version things, is there an > elf specialist in the house who can help? >=20 > Kris said can do the pbi tools part if he has help with these > two areas >=20 > Julian --o8+9QDyhj41GtdBs Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkvC+10ACgkQC3+MBN1Mb4ih7QCg0EhLIogQDMRpkf/pAma6mcGZ zaMAnRJbKsWpveNjEMqhRPHVsJ3MIVum =tvM8 -----END PGP SIGNATURE----- --o8+9QDyhj41GtdBs--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100412105214.GA2415>