ports and PBIs

[Kostik Belousov]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20100412/6922808e/attachment.pgp