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
_______________________________________________
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
