Re: ports and PBIs

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"?
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.


> 
> 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
> 
> 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 
> path  (x) or path (y).
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 
> Julian