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@g.o mailing list
|
