From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Ny2Az-0003y4-2k for garchives@archives.gentoo.org; Sat, 03 Apr 2010 12:10:09 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E81E0E079A; Sat, 3 Apr 2010 12:10:06 +0000 (UTC) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by pigeon.gentoo.org (Postfix) with ESMTP id 22629E0728 for ; Sat, 3 Apr 2010 12:09:57 +0000 (UTC) Received: by fxm5 with SMTP id 5so2176051fxm.29 for ; Sat, 03 Apr 2010 05:09:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:references:in-reply-to:disposition-notification-to :mime-version:content-type:content-transfer-encoding:message-id; bh=/zdO08fHU3ZzBtg7WvHsckd8hXg647QWv1wfzlAI/Lo=; b=EgNUSp1UdxuOpvxccj/QUresVeHtXhDD/t6+Vv0JiP23JuI3FaeF2tdcZvPsXBul9Q t0PRs7gUtjJvUIcUk6c1IdCoMx3pneOoU3MxDkzF8aFbhgiqxIIqFkdOGqR/RJkHfyqH xSE5as4yb3KCqVcR5UK9n6sdLFXLWUDCSKLCw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:references:in-reply-to :disposition-notification-to:mime-version:content-type :content-transfer-encoding:message-id; b=ay3DW/+Nc1S0MtrKeBehxr6qHYedHKMezFvrbHnGDoAQugZEsJEbLBlogAL++z0kT5 mFH4U9RbHNv7MXibg7nuAAMJ5mQzbrkL45GjAASxtwkxzmv6eoovHIylxw4ZicuaE3wr NIF2gNKUBs2R4ypX3aQTV+bF8jqOxnRhxwC9g= Received: by 10.87.67.8 with SMTP id u8mr4429886fgk.9.1270296596491; Sat, 03 Apr 2010 05:09:56 -0700 (PDT) Received: from lebrodyl.localnet (abxa214.neoplus.adsl.tpnet.pl [83.8.250.214]) by mx.google.com with ESMTPS id 16sm6945299fxm.8.2010.04.03.05.09.55 (version=SSLv3 cipher=RC4-MD5); Sat, 03 Apr 2010 05:09:56 -0700 (PDT) From: Maciej Mrozowski To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] More reliable hiding preserved libraries Date: Sat, 3 Apr 2010 14:09:42 +0200 User-Agent: KMail/1.13.2 (Linux/2.6.31-gentoo-r10; KDE/4.4.2; x86_64; ; ) References: <201004031238.18500.reavertm@gmail.com> <20100403105604.GO817@gentoo.org> In-Reply-To: <20100403105604.GO817@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Message-Id: <201004031409.43163.reavertm@gmail.com> Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 876c04fc-2b45-4857-a9f6-0eabf2412fdb X-Archives-Hash: 468305a4c236aeead1e0967aea7cbb2b On Saturday 03 of April 2010 12:56:04 Fabian Groffen wrote: > Is it known why this does happen exactly? When a lib is kept because i= t > is still used, only its soname + what the soname points to should be > kept. That would mean the lib can no longer be found during linking, > unless you add some trickery (or does GNU ld do something "handy" out o= f > the box right here?). So for example: >=20 > % ls > usr/lib/libfoo.so -> libfoo.so.2.1 > usr/lib/libfoo.so.2 -> libfoo.so.2.1 > usr/lib/libfoo.so.2.1 >=20 > % scanelf --soname usr/lib/libfoo.so > libfoo.so.2 usr/lib/libfoo.so >=20 > what should kept preserved is: >=20 > usr/lib/libfoo.so.2 -> libfoo.so.2.1 > usr/lib/libfoo.so.2.1 >=20 > because trying to link to libfoo using `gcc -o bar -lfoo bar.c` should > (in theory and on some platforms at least) fail. It doesn't matter, as 'broken' build system may alphabetically find libra= ry by=20 file name, and link to this library by full path. On Saturday 03 of April 2010 13:13:00 Micha=C5=82 G=C3=B3rny wrote: > > 2. During "emerge", unset environment variable corresponding to said > > preserved library directory - orphans are no longer located. > Wouldn't that cause failure when the toolkit relies on a 'hidden' > preserved library? It would indeed. Now when I think about it, moving stuff to preserved lib= rary=20 dir could be just done - provided it's possible - along with fixing/setti= ng=20 DT_RPATH's in reverse runtime dependencies. This way no system-wide=20 LIBRARY_PATH's would be necessary. Is it possible? Mike? On Saturday 03 of April 2010 13:33:16 Gilles Dartiguelongue wrote: > > There is opt-out suggestion[2], unfortunately it does not provide any > > info how exactly it's supposed to be achieved. As far as portage/pkgc= ore > > is concerned, maybe - as Brian Harring suggested - sandbox could be u= sed > > to somehow "hide" preserved libraries or preserved library directory > > from ebuild environment (preserved library directory a'ka "purgatory"= - > > libs could be moved there when considered orphaned). > that sounds nice, it would allow us to more easily spot > packages/upstreams doing it wrong (maybe that would work for packages > linking to themselves too btw) Keeping preserved libraries in separate location (in "purgatory" or dumpi= ng=20 place) is just a method for making implementation possibly easier (or pos= sible=20 at all), with nice side effects though. --=20 regards MM