public inbox for gentoo-soc@lists.gentoo.org
 help / color / mirror / Atom feed
From: "Lucian Poston" <lucianposton@gmail.com>
To: gentoo-soc@lists.gentoo.org
Cc: "Marius Mauch" <google-soc@genone.de>
Subject: [gentoo-soc] Progress Report - Revdep-rebuild
Date: Sun, 20 Jul 2008 04:23:12 -0500	[thread overview]
Message-ID: <c4cdc1420807200223t5cdb7d78u30503c5a8274de5b@mail.gmail.com> (raw)

Two major additions happened this week:

-A large part of the functionality that finds broken dependencies has
been moved into LinkageMap within pym/portage/dbapi/vartree.py.
listBrokenDependencies() and listProviders() were added as well as a
minor change to what was being added into the needed entries in
_obj_properties.  Empty strings were inserted into needed entries when
binaries had no needed entries in NEEDED.ELF.2.

-I resorted to masking directories and libraries to filter false
positives due to various reasons that are mentioned below.  The
existing SEARCH_DIRS_MASK and LD_LIBRARY_MASK variables from
/etc/revdep-rebuild/* are being used for now to mask special binaries
and directories, which are most often the result of binary packages.
This is the only way I've been able to filter binaries that are in
fact missing shared libraries according to my understanding of how the
dynamic linkers locates libraries (and what ldd reports).

vartree.py and sets.conf have been added to the repository at
http://repo.or.cz/w/revdep-rebuild-reimplementation.git

Replacing vartree.py and adding revdep.py and /etc/portage/sets.conf
should be enough to test out the set via emerge @missing-rebuild (you
may want to disable debug in sets.conf).  It's quite likely that many
packages are causing false positives.

Below are some examples of the types of edge cases I've encountered
and how they were resolved.

Lucian



------------------
www-client/mozilla-firefox-2.0.0.15
(/usr/lib/mozilla-firefox/plugins/libunixprintplugin.so)
386;/usr/lib/mozilla-firefox/plugins/libunixprintplugin.so;libunixprintplugin.so;$ORIGIN:/usr/lib/nspr;libxpcom.so,libxpcom_core.so,libplds4.so.6,libplc4.so.6,libnspr4.so.6,libpthread.so.0,libdl.so.2,libXt.so.6,libX11.so.6,libstdc++.so.6,libm.so.6,libgcc_s.so.1,libc.so.6

The previous requires the two following libs:

www-client/mozilla-firefox-2.0.0.15 (/usr/lib/mozilla-firefox/libxpcom.so)
386;/usr/lib/mozilla-firefox/libxpcom.so;libxpcom.so;$ORIGIN:/usr/lib/nspr;libplds4.so.6,libplc4.so.6,libnspr4.so.6,libpthread.so.0,libdl.so.2,libstdc++.so.6,libm.so.6,libgcc_s.so.1,libc.so.6

www-client/mozilla-firefox-2.0.0.15 (/usr/lib/mozilla-firefox/libxpcom_core.so)
386;/usr/lib/mozilla-firefox/libxpcom_core.so;libxpcom_core.so;$ORIGIN:/usr/lib/nspr;libplds4.so.6,libplc4.so.6,libnspr4.so.6,libpthread.so.0,libdl.so.2,libgtk-x11-2.0.so.0,libgdk-x11-2.0.so.0,libatk-1.0.so.0,libgdk_pixbuf-2.0.so.0,libpangocairo-1.0.so.0,libpango-1.0.so.0,libcairo.so.2,libgobject-2.0.so.0,libgmodule-2.0.so.0,libglib-2.0.so.0,libstdc++.so.6,libm.so.6,libgcc_s.so.1,libc.so.6

Notice that the two libs are needed; however, they are not located in
DT_RUNPATH of libunixprintplugin.so.
The rpath of libunixprintplugin.so includes
/usr/lib/mozilla-firefox/plugins; however, the required libs are in
/usr/lib/mozilla-firefox.

It would appear that the runpath for
libunixprintplugin.so should include $ORIGIN/.. rather than $ORIGIN.
I added a mask for /usr/lib/mozilla-firefox/plugins to deal with this.

------------------
app-emulation/vmware-workstation-5.5.7.91707
(/opt/vmware/workstation/lib/bin/vmware)
386;/opt/vmware/workstation/lib/bin/vmware;;;libdl.so.2,libm.so.6,libX11.so.6,libXext.so.6,libXi.so.6,libexpat.so.0,libfontconfig.so.1,libfreetype.so.6,libXrender.so.1,libXft.so.2,libglib-2.0.so.0,libgmodule-2.0.so.0,libgobject-2.0.so.0,libgthread-2.0.so.0,libatk-1.0.so.0,libpango-1.0.so.0,libpangoft2-1.0.so.0,libpangoxft-1.0.so.0,libpangox-1.0.so.0,libgdk-x11-2.0.so.0,libgdk_pixbuf-2.0.so.0,libgtk-x11-2.0.so.0,libgcc_s.so.1,libstdc++.so.5,libsigc-2.0.so.0,libglibmm-2.4.so.1,libglibmm_generate_extra_defs-2.4.so.1,libatkmm-1.6.so.1,libpangomm-1.4.so.1,libgdkmm-2.4.so.1,libgtkmm-2.4.so.1,libart_lgpl_2.so.2,libxml2.so.2,libglade-2.0.so.0,libgnomecanvas-2.so.0,libgnomecanvasmm-2.6.so.1,librsvg-2.so.2,libview.so.2,libsexy.so.1,libsexymm.so.1,libpthread.so.0,libz.so.1,libc.so.6,ld-linux.so.2

The previous requires the following:

app-emulation/vmware-workstation-5.5.7.91707
(/opt/vmware/workstation/lib/lib/libview.so.2/libview.so.2)
386;/opt/vmware/workstation/lib/lib/libview.so.2/libview.so.2;libview.so.2;/usr/lib/.;libgtkmm-2.4.so.1,libgdkmm-2.4.so.1,libatkmm-1.6.so.1,libgtk-x11-2.0.so.0,libpangomm-1.4.so.1,libglibmm-2.4.so.1,libsigc-2.0.so.0,libgdk-x11-2.0.so.0,libatk-1.0.so.0,libgdk_pixbuf-2.0.so.0,libpangoxft-1.0.so.0,libpangox-1.0.so.0,libpango-1.0.so.0,libgobject-2.0.so.0,libgmodule-2.0.so.0,libdl.so.2,libglib-2.0.so.0,libstdc++.so.5,libm.so.6,libc.so.6,libgcc_s.so.1

app-emulation/vmware-workstation-5.5.7.91707
(/opt/vmware/workstation/lib/lib/libpangomm-1.4.so.1/libpangomm-1.4.so.1)
386;/opt/vmware/workstation/lib/lib/libpangomm-1.4.so.1/libpangomm-1.4.so.1;libpangomm-1.4.so.1;/usr/lib/.;libglibmm-2.4.so.1,libsigc-2.0.so.0,libpango-1.0.so.0,libgobject-2.0.so.0,libgmodule-2.0.so.0,libdl.so.2,libglib-2.0.so.0,libstdc++.so.5,libm.so.6,libc.so.6,libgcc_s.so.1

app-emulation/vmware-workstation-5.5.7.91707
(/opt/vmware/workstation/lib/lib/libexpat.so.0/libexpat.so.0)
386;/opt/vmware/workstation/lib/lib/libexpat.so.0/libexpat.so.0;libexpat.so.0;;libc.so.6

Not in rpath.  I assume this is a bug or special binaries.
/opt/vmware/workstation/lib/bin isn't in $PATH anyhow.  I don't know
why binary packages have to be so rebellious.  I had to add a mask for
/opt/vmware/workstation/lib.

--------------------
dev-java/sun-jdk-1.6.0.06 (/opt/sun-jdk-1.6.0.06/jre/lib/i386/libjawt.so)
386;/opt/sun-jdk-1.6.0.06/jre/lib/i386/libjawt.so;libjawt.so;$ORIGIN;libmawt.so,libjvm.so,libc.so.6

The previous requires one of the following:

dev-java/sun-jdk-1.6.0.06
(/opt/sun-jdk-1.6.0.06/jre/lib/i386/motif21/libmawt.so)
386;/opt/sun-jdk-1.6.0.06/jre/lib/i386/xawt/libmawt.so;libmawt.so;$ORIGIN:$ORIGIN/..;libpthread.so.0,libm.so.6,libXext.so.6,libX11.so.6,libdl.so.2,libXtst.so.6,libXi.so.6,libjvm.so,libc.so.6

dev-java/sun-jdk-1.6.0.06
(/opt/sun-jdk-1.6.0.06/jre/lib/i386/headless/libmawt.so)
386;/opt/sun-jdk-1.6.0.06/jre/lib/i386/motif21/libmawt.so;libmawt.so;$ORIGIN:$ORIGIN/..;libXp.so.6,libXtst.so.6,libXext.so.6,libX11.so.6,libXi.so.6,libjvm.so,libm.so.6,libdl.so.2,libc.so.6

dev-java/sun-jdk-1.6.0.06 (/opt/sun-jdk-1.6.0.06/jre/lib/i386/xawt/libmawt.so)
386;/opt/sun-jdk-1.6.0.06/jre/lib/i386/headless/libmawt.so;libmawt.so;$ORIGIN:$ORIGIN/..;libjvm.so,libm.so.6,libdl.so.2,libc.so.6

Not in rpath. The rpath of libjawt.so includes
/opt/sun-jdk-1.6.0.06/jre/lib/i386, but the required lib(s) are a
level deeper.  The existing masks in /etc/revdep-rebuild/* covered these.

--------------------
dev-java/sun-jdk-1.6.0.06 (/opt/sun-jdk-1.6.0.06/jre/lib/i386/libJdbcOdbc.so)
386;/opt/sun-jdk-1.6.0.06/jre/lib/i386/libJdbcOdbc.so;libJdbcOdbc.so;$ORIGIN;libodbcinst.so,libodbc.so,libjvm.so,libc.so.6

The previous requires libodbcinst.so and libodbc.so, which are not
installed by this package or any dependencies.
The existing masks in /etc/revdep-rebuild/* covered these.

--------------------
app-office/openoffice-bin-2.4.1
(/usr/lib/openoffice/program/hatchwindowfactory.uno.so ->
hatchwindowfactory.uno.so.1.1)
386;/usr/lib/openoffice/program/hatchwindowfactory.uno.so.1.1;;$ORIGIN:$ORIGIN/../ure-link/lib;libtk680li.so,libvcl680li.so,libtl680li.so,libuno_cppuhelpergcc3.so.3,libuno_cppu.so.3,libuno_sal.so.3,libdl.so.2,libpthread.so.0,libstlport_gcc.so,libstdc++.so.6,libm.so.6,libgcc_s.so.1,libc.so.6

The previous requires the following:

app-office/openoffice-bin-2.4.1
(/usr/lib/openoffice/program/libstlport_gcc.so -> libstlport_gcc.so.1)
386;/usr/lib/openoffice/program/libstlport_gcc.so.1;;$ORIGIN;libm.so.6,libc.so.6

app-office/openoffice-bin-2.4.1
(/usr/lib/openoffice/program/libvcl680li.so -> libvcl680li.so.1.1)
386;/usr/lib/openoffice/program/libvcl680li.so.1.1;;$ORIGIN:$ORIGIN/../ure-link/lib;libpsp680li.so,libsot680li.so,libutl680li.so,libtl680li.so,libi18nisolang1gcc3.so,libcomphelp4gcc3.so,libucbhelper4gcc3.so,libuno_cppuhelpergcc3.so.3,libuno_cppu.so.3,libvos3gcc3.so,libuno_sal.so.3,libbasegfx680li.so,libicuuc.so.36,libicule.so.36,libjvmaccessgcc3.so.3,libfreetype.so.6,libX11.so.6,libXext.so.6,libdl.so.2,libpthread.so.0,libstlport_gcc.so,libstdc++.so.6,libm.so.6,libgcc_s.so.1,libc.so.6

app-office/openoffice-bin-2.4.1
(/usr/lib/openoffice/program/libtk680li.so -> libtk680li.so.1.1)
386;/usr/lib/openoffice/program/libtk680li.so.1.1;;$ORIGIN:$ORIGIN/../ure-link/lib;libvos3gcc3.so,libvcl680li.so,libsot680li.so,libutl680li.so,libtl680li.so,libcomphelp4gcc3.so,libuno_cppuhelpergcc3.so.3,libuno_cppu.so.3,libuno_sal.so.3,libX11.so.6,libdl.so.2,libpthread.so.0,libstlport_gcc.so,libstdc++.so.6,libm.so.6,libgcc_s.so.1,libc.so.6

The required libs are in rpath; however, they are missing sonames, so
LinkageMap can't add provider info into _libs.
Bugs in the package, I assume.  A little hack in
listBrokenDependencies() covered the case of missing sonames within
libraries (though these happen to be masked anyway).

--------------------
net-analyzer/netcat-110-r8 (/usr/bin/nc)
386;/usr/bin/nc;;;libmix.so,libc.so.6

The previous requires:

dev-libs/libmix-2.05 (/usr/lib/libmix.so)
386;/usr/lib/libmix.so;;;libc.so.6

Same as above. Missing soname in libmix.so.
Seems to be a bug.

------------------
x11-drivers/nvidia-drivers-173.14.09
(/usr/lib/opengl/nvidia/lib/libGL.so -> libGL.so.173.14.09)
386;/usr/lib/opengl/nvidia/lib/libGL.so.173.14.09;libGL.so.1;;libGLcore.so.1,libnvidia-tls.so.1,libm.so.6,libXext.so.6,libX11.so.6,libdl.so.2,libc.so.6

The previous requires the following:

x11-drivers/nvidia-drivers-173.14.09
(/usr/lib/opengl/nvidia/lib/libnvidia-tls.so ->
../tls/libnvidia-tls.so)
386;/usr/lib/opengl/nvidia/tls/libnvidia-tls.so.173.14.09;libnvidia-tls.so.1;;

The symlink is in rpath, but target is not. Only the target's path is
stored in LinkageMap, so the need is unsatisfied according to
findProviders().
listBrokenDependencies() checks for this case (only symlinks in runpath).

--------------------



             reply	other threads:[~2008-07-20  9:23 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-20  9:23 Lucian Poston [this message]
  -- strict thread matches above, loose matches on Subject: below --
2008-08-21  3:09 [gentoo-soc] Progress Report - Revdep-rebuild Lucian Poston
2008-08-21 15:47 ` Donnie Berkholz
2008-08-21 18:09   ` Lucian Poston
2008-08-11 23:12 Lucian Poston
2008-08-01 21:24 Lucian Poston
2008-07-27  6:28 Lucian Poston
2008-07-12  3:13 Lucian Poston
2008-06-26  1:30 Lucian Poston
2008-06-26 17:47 ` Marius Mauch
2008-06-15  3:55 Lucian Poston
2008-06-17 15:55 ` Marius Mauch
2008-06-15  3:34 Lucian Poston

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c4cdc1420807200223t5cdb7d78u30503c5a8274de5b@mail.gmail.com \
    --to=lucianposton@gmail.com \
    --cc=gentoo-soc@lists.gentoo.org \
    --cc=google-soc@genone.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox