Hi guys, I've upgraded GCC from 3.2.2 to gcc-3.4.1-r2 (+hardened, +pie and +pic and -fstack-protector) and ran revdep-rebuild and it recompiled lib-compat-1.3, java and nothing else. Yet pam (among others) failed to compile - until I manually reemerged glib-1.2.10.. and glib-2.. and others pam depends on. Is it not the job of revdep-rebuild to rebuild these packages? -- the pam failure output - which is resolved - without revdep-rebuild's help. Now I ran emerge -uDav world but pam fails to compile Sad ...config.y:327: warning: 'set_permissions_single' defined but not used config.y:367: warning: 'reset_permissions_single' defined but not used config.lex.c:1432: warning: '_pc_yy_delete_buffer' defined but not used config.lex.c:1549: warning: '_pc_yy_scan_string' defined but not used config.lex.c:1227: warning: 'yyunput' defined but not used config.y:467: warning: 'do_yyerror' defined but not used //usr/lib/libglib.a(gstrfuncs.o)(.text+0x8c2): In function `g_strdown': : undefined reference to `__ctype_tolower' //usr/lib/libglib.a(gstrfuncs.o)(.text+0x942): In function `g_strup': : undefined reference to `__ctype_toupper' //usr/lib/libglib.a(gstrfuncs.o)(.text+0xc76): In function `g_strchug': : undefined reference to `__ctype_b' //usr/lib/libglib.a(gstrfuncs.o)(.text+0xd49): In function `g_strchomp': : undefined reference to `__ctype_b' //usr/lib/libglib.a(gstring.o)(.text+0xda6): In function `g_string_down': : undefined reference to `__ctype_tolower' //usr/lib/libglib.a(gstring.o)(.text+0xe36): In function `g_string_up': : undefined reference to `__ctype_toupper' collect2: ld returned 1 exit status make[2]: *** [pam_console_apply] Error 1 make[2]: Leaving directory `/var/tmp/portage/pam-0.77/work/Linux-PAM-0.77/modules/pam_console' make[1]: *** [all] Error 1 make[1]: Leaving directory `/var/tmp/portage/pam-0.77/work/Linux-PAM-0.77/modules' make: *** [modules] Error 2 !!! ERROR: sys-libs/pam-0.77 failed. Reproducible: Always Steps to Reproduce: 1. upgrade glibc from 2.3.1 to 2.3.4.. and gcc from f.ex. 3.2.2 to 3.4.1 2. run revdep-rebuild Actual Results: revdep-rebuild recompiled lib-compat-1.3, java and nothing else. Expected Results: Recompiled almost ALL packages on the system (incl. pam, courier-imap, mysql, openssh etc.).
I forund a similar problem today after the new flac libs where emerged it tries to recompile kedmultimedia without 1st recompiling arts and kdelibs.
I will try to reproduce this to see if I've fixed this with the updated version of revdep-rebuild that I'm working on.
I've looked into the new libFLAC situation noted and I fail to see the problem. While kdemultimedia does depend upon arts and kdelibs, there is nothing broken in those two packages, so why do they need to be recompiled as well? As far as the upgraded GCC version situation, I don't currently have a box that I'm willing to load gcc 3.4 on for testing.
after the libFLAC update kdemultimedia would not recompile until kdelibs had been recompiled and then arts would segfault until it was rebuilt, maybe something else broke those but it was what I found. If some thing else did break them should revdep-rebuild not have picked that up as well?
What was the exact revdep-rebuild command that you ran?
Just the default revdep-rebuild
And me too - just ran: revdep-rebuild
Same here after upgrading to gcc-3.4.2. kdemultimedia compilation fails this way: /bin/sh ../../libtool --silent --mode=compile --tag=CXX g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/kde/3.3/include -I/usr/qt/3/include -I/usr/X11R6/include -I/usr/include/taglib -DQT_THREAD_SUPPORT -D_REENTRANT -Wnon-virtual-dtor -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -Wwrite-strings -g3 -fno-inline -O2 -pipe -Wformat-security -Wmissing-format-attribute -fno-exceptions -fno-check-new -fno-common -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -c -o kfile_mp3.lo `test -f 'kfile_mp3.cpp' || echo './'`kfile_mp3.cpp /bin/sh ../../libtool --silent --mode=link --tag=CXX g++ -Wnon-virtual-dtor -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -Wwrite-strings -g3 -fno-inline -O2 -pipe -Wformat-security -Wmissing-format-attribute -fno-exceptions -fno-check-new -fno-common -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -o kfile_mp3.la -rpath /usr/kde/3.3/lib/kde3 -L/usr/X11R6/lib64 -L/usr/qt/3/lib -L/usr/kde/3.3/lib -L/usr/lib -ltag -module -avoid-version -module -no-undefined -Wl,--no-undefined -Wl,--allow-shlib-undefined -R /usr/kde/3.3/lib -R /usr/qt/3/lib -R /usr/X11R6/lib64 kfile_mp3.lo -lkio .libs/kfile_mp3.o(.gnu.linkonce.t._ZNSt4listIN6TagLib6StringESaIS1_EE9_M_insertESt14_List_iteratorIS1_ERKS1_+0x14): In function `std::list<TagLib::String, std::allocator<TagLib::String> >::_M_insert(std::_List_iterator<TagLib::String>, TagLib::String const&)': /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.2/include/g++-v3/bits/stl_list.h:1162: undefined reference to `std::_List_node_base::hook(std::_List_node_base*)' collect2: ld returned 1 exit status make[3]: *** [kfile_mp3.la] Error 1 make[3]: Leaving directory `/home/var/tmp/portage/kdemultimedia-3.3.0/work/kdemultimedia-3.3.0/kfile-plugins/mp3' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/var/tmp/portage/kdemultimedia-3.3.0/work/kdemultimedia-3.3.0/kfile-plugins' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/var/tmp/portage/kdemultimedia-3.3.0/work/kdemultimedia-3.3.0' make: *** [all] Error 2 !!! ERROR: kde-base/kdemultimedia-3.3.0 failed. !!! Function kde_src_compile, Line 142, Exitcode 2 !!! died running emake, kde_src_compile:make !!! If you need support, post the topmost build error, NOT this status message. I'm currently re-emerging kdelibs, I'll keep you posted
after manually re-emerging kdelibs, kdemultimedia merged successfully
As far as I can tell, all of these problems are beyond the scope of revdep-rebuild. The purpose of revdep-rebuild is to rebuild packages that have broken dynamic linking. In all of these cases, it has done what it was designed to do.
I thought revdep-rebuild was to resolve dependencies of applications when libraries where updated and I agree with the original post it does not do what it should. The 1st comment on this report says it all. Maybe it is not possible for revdep-rebuild to do this but we surely require a tool which will resovle all these issues if Gentoo is to make it into the mainstream and not just be for Linux the guru. I found in my case that some libarary update had broken QT and recompiling that with kdelibs solved the problem after much scratching of heads. I would have thought that this would have been resolved by revdep-rebuild?
I too thought that revdep-rebuild scanned for .so bindings (output of ldd filename) to see what it depended on - and thus if it has to be recompiled to build a reverse-dependencies tree on-the-fly. I helped design (and gentoo@insaneone.com wrote it - ie. Michael) a reverse dependencies patch (actually hooks in portage, that called a few perl programs). It worked perfectly actually - and made portage tell you what programs to recompile before (and after) updating gcc. ie. it wouldn't normally allow you to recompile php with mysql support, if you had recompiled gcc - and not mysql yet. The idea was based on my old GLEP proposal (I can't find the updated one we wrote together - so you'll have to bare with me ;) http://vsen.dk/files/GLEP-Making_updates_never_break_dependencies.txt It was implemented as a proof-of-concept - but the portage dev(s) rejected it, as they had their own plans for implementing reverse dependencies (although our proof-of-concept was none-intrusive due to the hooks - and didn't take Michael more than a day to write - in first revision). We abandoned it, because it appereantly had no chance of getting into portage - and Michael got tired of keeping the patch up2date with portage. I found the original bug about it: http://bugs.gentoo.org/show_bug.cgi?id=1991 but can't seem to find the patch on any of my machines right now.. :( If you are interested in actually doing something, to implement reverse-dependencies - I can go find the source - if nothing else by writing Michael :)
Small revision to previous statement :) It would add mysql to the list of things having to be recompiled - before compiling php. So it would actually emerge php, as requested - but mysql recompilation would be added as a dependency, because of the reverse dependencies - and the fact that mysql hadn't been recompiled since an upgrade of something it depended on. I hope that made the purpose clearer :)
*** Bug 84715 has been marked as a duplicate of this bug. ***
*** Bug 80066 has been marked as a duplicate of this bug. ***
After an update of libtool today left many packages with boken depends revdep-rebuild did not detect any of them. Some where openssl, kdelibs, gnomemeeting and many other kde packages.
problem might be that revdep-rebuild does not strip path/to/some/missing libs before finnding what ebuilds is brokken, can be tested with equery b /usr/lib/libGL.so.1 this will not tell what ebuild is resposible for libGL.so.1 equery b libGL.so.1 does works here is revdep-rebuild does that ?
This bug is basically unfixable, until someone can come up with a reliable method for determining unresolved symbols. I have tried using ldd -d -r to identify the unresolved symbols and it results in an excessive amount of false positives. (On my system 85 packages were reported as being broken with this implementation, when only one of them was actually broken). If someone has a reliable method to determine the unresolved symbols, please comment and ask that this bug be reopened.
(In reply to comment #18) > If someone has a reliable method to determine the unresolved symbols, please > comment and ask that this bug be reopened. Did you talk with solar or vapier about this yet?
(In reply to comment #19) > > If someone has a reliable method to determine the unresolved symbols, please > > comment and ask that this bug be reopened. > > Did you talk with solar or vapier about this yet? Yes, I've talked to them several times in the past. Everything that I have tried to implement leads to too many false positives.
*** Bug 253031 has been marked as a duplicate of this bug. ***
(In reply to comment #18) > If someone has a reliable method to determine the unresolved symbols, please > comment and ask that this bug be reopened. I've kept an updated version of the patch attached to bug #162589 (which should probably be closed as a duplicate of this, and this reopened) around locally, which uses ldd -d -r for everything except *.so and *.so.*, and haven't had problems with false positives.
*** Bug 312955 has been marked as a duplicate of this bug. ***
Reopening. We need to make a decision to either detect unresolved symbols or not.
(In reply to comment #24) > Reopening. We need to make a decision to either detect unresolved symbols or > not. In my opinion, it should be optional (i.e. triggered by a specific switch).
Let's target adding a command line option in 0.3.1 to try to detect symbol breakage.
*** Bug 162589 has been marked as a duplicate of this bug. ***
i feel like i implemented this once in the past with pax-utils, but i can't find that code. should be somewhat easy to add to lddtree.py though i think.
*** Bug 527484 has been marked as a duplicate of this bug. ***
Could the approach from https://bugs.gentoo.org/attachment.cgi?id=178002 (checking in binaries but not in .so.* files to prevent false positives) be considered? Would be really useful with breakages like bug 513386
Created attachment 388478 [details] revdep-rebuild.sh to detect symbol not defined This version of revdep-rebuild.sh uses ldd -d -r to detect symbol not defined errors.
It tries to rebuild this: emerge --complete-graph=y --oneshot --autounmask-write --keep-going gnome-base/gnome-control-center:2 gnome-extra/yelp:0 gnome-extra/zenity:0 mail-client/evolution:2.0 media-gfx/shotwell:0 net-im/empathy:0 net-libs/gnome-online-accounts:0/1 net-libs/webkit-gtk:3/25 www-client/epiphany:0 x11-libs/cairo:0 Not sure if it's intentional... for this concrete case looks like rebuilding only the package providing the offending library pointed by "ldd -r -d" output (in this case webkit-gtk) is enough
Since my system is not broken, can you paste the full output from the revdep-rebuild run, so I can see what it was detecting?
Created attachment 388572 [details] revdep-rebuild output Sure :)
Created attachment 389053 [details] Updated revdep-rebuild.sh Okay, please test this version and see how it works. This will look for "symbol not defined" errors unconditionally. If you specify -u or --search-symbols it will look for "undefined symbols". This option does give me false positives on my system, but may be useful for finding issues. If the initial testing looks good, I will commit the changes to the git repository.
plain "revdep-rebuild" works fine, thanks :D Regarding the new "-u" option, looks like "-u" is not recognized and I need to run with the "longer" option :) # revdep-rebuild -u Encountered unrecognized option -u. revdep-rebuild no longer automatically passes unrecognized options to portage. Separate emerge-only options from revdep-rebuild options with the -- flag. For example, revdep-rebuild -v -- --ask See the man page or revdep-rebuild -h for more detail. That toggle also causes some false positives to be shown... but I guess it's expected :)
I've fixed -u to work correctly as an option and pushed the changes to git. These changes can continue to be tested / used with app-portage/gentoolkit-9999 until I get a new release of gentoolkit pushed. Please note that this functionality is only implemented in the bash version of revdep-rebuild, it is not implemented in the python version.
It works fine, thanks! :)
Do you plan to release a new gentoolkit version in the near future? :)
*** Bug 565586 has been marked as a duplicate of this bug. ***
Not supported in the python version of revdep-rebuild.
