From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from <gentoo-soc+bounces-264-garchives=archives.gentoo.org@lists.gentoo.org>) id 1KBgJQ-0005vk-0b for garchives@archives.gentoo.org; Thu, 26 Jun 2008 01:30:12 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2350DE01E0; Thu, 26 Jun 2008 01:30:11 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id C9478E01E0 for <gentoo-soc@lists.gentoo.org>; Thu, 26 Jun 2008 01:30:10 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 5553D673CA for <gentoo-soc@lists.gentoo.org>; Thu, 26 Jun 2008 01:30:10 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: 0.111 X-Spam-Level: X-Spam-Status: No, score=0.111 required=5.5 tests=[AWL=2.710, BAYES_00=-2.599] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0NCzsh1kTLk for <gentoo-soc@lists.gentoo.org>; Thu, 26 Jun 2008 01:30:03 +0000 (UTC) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.234]) by smtp.gentoo.org (Postfix) with ESMTP id 5574A67255 for <gentoo-soc@gentoo.org>; Thu, 26 Jun 2008 01:30:02 +0000 (UTC) Received: by wr-out-0506.google.com with SMTP id 58so2866884wri.8 for <gentoo-soc@gentoo.org>; Wed, 25 Jun 2008 18:30:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:mime-version:content-type:content-transfer-encoding :content-disposition:x-google-sender-auth; bh=I8V5BtNN68N/HzZMspH0uN5ZSGmqdE4Ndl6up5hfCRU=; b=uPL44n1soJ1aHw3jQ5kpAXHZPjNYqnkfY8AT/obquRbcb09RJ7i2iFGtkWlREiUXiW 7LXH7SwWw68qEurnIr6xQ83L9IFBBa0cTXG65c8oQD37J/614jfXwJrt94d2gyEPfmaM 4TUUXyQeDnlG5C7TpVSJN51VTEo9L0EsXtEcM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:mime-version:content-type :content-transfer-encoding:content-disposition:x-google-sender-auth; b=E6ibNbgJmIhwDQvB2MrjFefwr0ztR4qoZWiMEukLZ8sVjcjzmwuSNdNbDr2Sfk64qS F88PpnUdorL+sU2w4SisvnYwPncN3pMh/EUpcfoc6GV68r2frD6vAaiT4ypu8rymaC2d QyytHLnSJXoheem3zGN6CPI1j48sJ5TSkY0Eo= Received: by 10.90.114.19 with SMTP id m19mr14573198agc.32.1214443802286; Wed, 25 Jun 2008 18:30:02 -0700 (PDT) Received: by 10.90.84.6 with HTTP; Wed, 25 Jun 2008 18:30:02 -0700 (PDT) Message-ID: <c4cdc1420806251830g7c70758dp53f3c334b80f2305@mail.gmail.com> Date: Wed, 25 Jun 2008 20:30:02 -0500 From: "Lucian Poston" <lucianposton@gmail.com> Sender: lucian.poston@gmail.com To: gentoo-soc@lists.gentoo.org Subject: [gentoo-soc] Progress Report - Revdep-rebuild Cc: "Marius Mauch" <google-soc@genone.de> Precedence: bulk List-Post: <mailto:gentoo-soc@lists.gentoo.org> List-Help: <mailto:gentoo-soc+help@lists.gentoo.org> List-Unsubscribe: <mailto:gentoo-soc+unsubscribe@lists.gentoo.org> List-Subscribe: <mailto:gentoo-soc+subscribe@lists.gentoo.org> List-Id: Gentoo Linux mail <gentoo-soc.gentoo.org> X-BeenThere: gentoo-soc@lists.gentoo.org Reply-to: gentoo-soc@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 79efd348af43322d X-Archives-Salt: 1e2fd957-2d8f-4dd5-8889-bbd6c466223f X-Archives-Hash: 6af32326690fae4fc662405703e82b28 As mentioned last week, I created lists of "needed" libs and "installed" libs. I was hoping that the difference would produce a set of "missing" libs, but I encountered several problems with that, which I discuss below. The list of "needed" libraries is found by calling findProviders() on all installed files listed in each atom's CONTENTS. It's inefficient, but once I'm able to find a solution to the problems mentioned below, I will try a different implementation to build a list of "needed" libs, most likely by creating another method in LinkageMap (if that is okay). A couple libraries that I've questions about: libodbc.so; libodbcinst.so; libgdbm.so.2; libdb-3.1.so; libcrypto.so.0.9.6: dev-java/sun-jdk-1.6.0.05/NEEDED.ELF.2: 386;/opt/sun-jdk-1.6.0.05/jre/lib/i386/libJdbcOdbc.so;libJdbcOdbc.so;$ORIGIN;libodbcinst.so,libodbc.so,libjvm.so,libc.so.6 app-office/openoffice-bin-2.4.0/NEEDED.ELF.2: 386;/usr/lib/openoffice/program/python-core-2.3.4/lib/lib-dynload/dbm.so;;;libgdbm.so.2,libpthread.so.0,libc.so.6 These libraries are needed as shown above; however, they are not in the filesystem and consequently have no scanelf entries in any NEEDED file. How are they dynamically linked when the library isn't installed? I'm not sure what's going on with these libraries at all. ld-linux.so.2 -> ld-2.6.1.so: This is installed by sys-libs/glibc-2.6.1; however, it has no entry in any NEEDED file. Scanning the library myself produces EM_386;/lib/ld-2.6.1.so;ld-linux.so.2;;. I'd assume that the dynamic linker would also have a NEEDED file entry for consistency, but it doesn't. Is there a reason why? libGLcore.so.1; libnvidia-tls.so.1: Similar to above, these libraries from x11-drivers/nvidia-drivers-169.09-r1 are installed and dynamically linked to other libraries, but they have no entry in a NEEDED file. For libGLcore.so.1, scanelf produced EM_386;/usr/lib/opengl/nvidia/lib/libGLcore.so.169.09;libGLcore.so.1;; libmix.so: dev-libs/libmix-2.05/NEEDED.ELF.2: 386;/usr/lib/libmix.so;;;libc.so.6 It is a part of dev-libs/libmix-2.05 and needed by /usr/bin/nc, which is in net-analyzer/netcat-110-r8. This library is installed and has an entry in a NEEDED file, but that scanelf entry has no soname. A couple other libraries (eg libpython2.3.so.1.0, libview.so.2, libatkmm-1.6.so.1, libcrypto.so.0.9.7, libglibmm-2.4.so.1), which are part of app-office/openoffice-bin-2.4.0 or app-emulation/vmware-workstation-5.5.5.56455, are located in directories, which are not in portage.util.getlibpaths(). As a consequence of the previous situations, the dict returned by findProviders() includes all the previously needed libraries as keys, but their associated values are the empty set. I'm unsure if these libraries should be ignored or if some other action should be taken. My current problem is that I was expecting findProviders() to return the empty set for binaries which are missing libraries, and thus those binaries need to be re-emerged, but the above situations complicate things because those libraries also map to the empty set. Hopefully, I am able to reduce these irregularities into more general cases so that what I've done so far has not been in vain. :) For the next week, I'll attempt to resolve these issues, which will likely lead me back to reading the old revdep-rebuild script. The code is hosted at http://repo.or.cz/w/revdep-rebuild-reimplementation.git?a=tree -Lucian -- gentoo-soc@lists.gentoo.org mailing list