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=en&a=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"? > > You interpreted the question correctly. > > >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. > > 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. > > 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. > > If the library is actually somewhere else (via symlink) is $origin > reevaluated to the actual destination? (that would be cool). No. > > > > > > > >> > >>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 > > and libraries A and B in "common area" can be updated for security > reasons by a special kind of PBI or package should it be required. > > It sounds to me that link 'y' is followed, i.e. the linker continues > to think it is working in $ORIGIN(A). > > either way this is sounding very doable.. Kris is thinking about a > single sysutils/pbimanager port and a /mk diff that would allow > "make pbi" (once the port was installed). > > I think it actually looks quite feasible. > > Is there someone out there in ports-land who really inderstands the > ports mk framework who could help us (because we'll need a local guide > to make sure we don't dig inn any local burial grounds) and who can > help with testing etc? > > Similarly if we need to do anything funny with regards to hashing > parts of .so files, or deciding how to version things, is there an > elf specialist in the house who can help? > > Kris said can do the pbi tools part if he has help with these > two areas > > Julian
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:02 UTC