Re: ports and PBIs

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?

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 ?

If the library is actually somewhere else (via symlink) is $origin 
reevaluated to the actual destination? (that would be cool).


>
>
>>
>> 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