Summary: | emerge @preserved-rebuild fails to remove libs having multiple providers of the same soname, like libffi.so from gcc-4.4.1 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Steffen Hau <steffen> |
Component: | New packages | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | arfrever, dschridde+gentoobugs, enrico.tagliavini, esigra, joshua.rich, kanelxake, ssuominen |
Priority: | High | Keywords: | InVCS |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 240323 |
Description
Steffen Hau
2009-10-15 08:57:01 UTC
Just to make this clear: Do you have libffi.so* in /usr/lib installed by dev-libs/libffi (or some other provider, if there are more)? Yes, dev-libs/libffi is installed. schlepptop ~ # equery f libffi * Searching for libffi ... * Contents of dev-libs/libffi-3.0.8: /usr /usr/lib /usr/lib/libffi-3.0.8 /usr/lib/libffi-3.0.8/include /usr/lib/libffi-3.0.8/include/ffi.h /usr/lib/libffi-3.0.8/include/ffitarget.h /usr/lib/libffi.la /usr/lib/libffi.so -> libffi.so.5.0.9 /usr/lib/libffi.so.5 -> libffi.so.5.0.9 /usr/lib/libffi.so.5.0.9 As I said, python gets linked against those libs, if I manually delete the libffi.so* from gcc. This ld.so.conf conflict is exactly why I masked the USE libffi for sys-devel/gcc in the first place. This is bad, if portage doesn't know howto handle it. Guys, I just got the exact same problem with GCC 4.5.2, libffi 3.0.9-r1 and the the following packages not going out of @preserved-rebuild: dev-java/jna-3.2.4 dev-lang/python-3.1.3 dev-lang/python-2.7.1 I don’t really understand how to properly fix this. I mean so that it will never ever return for anyone who’s using Gentoo. And as a temporary workaround also so that it won’t return for me, without causing any errors. Just deleting those libs sounds like a recipe for disaster. Maybe we can figure out why the .so (without version) is preserved, as it shouldn't have in the first place. Same thing as Comment #4 is happening here also. The libffi use flag mask has been there since 2009, is it really necessary anymore? (In reply to comment #6) > Same thing as Comment #4 is happening here also. The libffi use flag mask has > been there since 2009, is it really necessary anymore? > What do you mean? It's there to stay. The USE="libffi" is not supposed to be used at all. dev-libs/libffi is the maintained copy. *** Bug 354903 has been marked as a duplicate of this bug. *** The issue hit me with gcc-4.4.5, too. Getting rid of the wrong link against libffi.so.4 for python:{2.7,3.2} was easy: I just deleted the offending libraries. However, icedtea-6.1.10.1 here also linked against libffi.so.4, and deleting that file prevents javac from running, which in turn prevents icedtea:6 from bootstrapping (if gcj is not available). Hence a simple rebuild of icedtea to clear the dep is impossible. I am currently trying to build it with a manually created "libffi.so.4 -> libffi.so.5" symlink, which seems to work rather well. The issue hit me with gcc-4.4.5, too. Getting rid of the wrong link against libffi.so.4 for python:{2.7,3.2} was easy: I just deleted the offending libraries. However, icedtea-6.1.10.1 here also linked against libffi.so.4, and deleting that file prevents javac from running, which in turn prevents icedtea:6 from bootstrapping (if gcj is not available). Hence a simple rebuild of icedtea to clear the dep is impossible. I am currently trying to build it with a manually created "libffi.so.4 -> libffi.so.5" symlink, which seems to work rather well. Still true for gcc-4.5.2 As I understand it, the problem is triggered by the fact that LinkageMapELF.findConsumers() is greedy in identifying consumers of a given library, even though there may be an alternative library file providing the same soname to the identified consumers. This greedy behavior will be fine as long as we account for it inside the dblink _find_libs_to_preserve and _find_unused_preserved_libs methods. When counting references to libraries, these methods to be aware of alternative library files providing a given soname. *** Bug 284944 has been marked as a duplicate of this bug. *** *** Bug 305133 has been marked as a duplicate of this bug. *** (In reply to comment #12) > As I understand it, the problem is triggered by the fact that > LinkageMapELF.findConsumers() is greedy in identifying consumers of a given > library, even though there may be an alternative library file providing the > same soname to the identified consumers. It's fixed to handle this in git: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=296fc63fee262600811520fccf4692f47a39ffba This is fixed in 2.2.0_alpha46. *** Bug 205531 has been marked as a duplicate of this bug. *** |