From owner-freebsd-current@FreeBSD.ORG Sun Apr 11 22:44:39 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E221B106575F; Sun, 11 Apr 2010 22:44:39 +0000 (UTC) (envelope-from julianelischer@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.221.175]) by mx1.freebsd.org (Postfix) with ESMTP id B4B098FC18; Sun, 11 Apr 2010 22:44:38 +0000 (UTC) Received: by qyk5 with SMTP id 5so5745170qyk.3 for ; Sun, 11 Apr 2010 15:44:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=d2zJ+AQqj5w/HQQAVbgte3T8kWEvdIFw0Z4HzIZRRO8=; b=EKFHFNj+01iIylnxVYQG4Cm6BeoH6gvMBoBOMGXzKa5LT0VfSRKuzU7DPLkTis08IA IwL3BqsgIkoOxUUTgj3R/WUZd5mSvm+SjtfUgs4JZ1KGLVsbWDhOFkAU2y6joi3gGKM0 x+SywwxxRE2riLWAysrFao3aliYkYLeIT72iQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=mKeCqqywEqExiu1JTkLrnBAlDdPAF6ffzDbJ+32cANWsoKBtQPH/1l3ntl9gC4j5/f NMEfJmO6DrgX5NaC+FQ2VUqkWysGEs6k8DuBPVe5C6R3s+fZr3JMYZ5HGXq1ICkKX1Pn MUPZQdWkPOleFNfLvwE1a+nw2szbQpOBvsuwk= Received: by 10.229.14.157 with SMTP id g29mr1521799qca.57.1271025877649; Sun, 11 Apr 2010 15:44:37 -0700 (PDT) Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by mx.google.com with ESMTPS id v26sm5215269qce.7.2010.04.11.15.44.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 11 Apr 2010 15:44:37 -0700 (PDT) Sender: Julian Elischer Message-ID: <4BC250D5.7000608@elischer.org> Date: Sun, 11 Apr 2010 15:44:37 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Kostik Belousov References: <4BC03ABA.6090309@elischer.org> <4BC0CC6F.7010009@freebsd.org> <4BC0E9AE.1000904@elischer.org> <4BC0FF80.4000907@freebsd.org> <20100411102723.GT2415@deviant.kiev.zoral.com.ua> <4BC213A5.4020104@elischer.org> <20100411184406.GV2415@deviant.kiev.zoral.com.ua> <4BC21F48.8090407@elischer.org> <20100411192049.GX2415@deviant.kiev.zoral.com.ua> In-Reply-To: <20100411192049.GX2415@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ports@freebsd.org, FreeBSD Current , Kris Moore Subject: Re: ports and PBIs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2010 22:44:40 -0000 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