At the moment, my libSDL-1.2.so.0 seems to be broken. I guess, the problems came with a new version of libcaca - anyway, that's not my problem. The problem is, that revdep-rebuild doesn't recognize the problem. Here we go: # ldd /usr/lib/libSDL-1.2.so.0 linux-gate.so.1 => (0xb7fbf000) libm.so.6 => /lib/libm.so.6 (0xb7f27000) libdl.so.2 => /lib/libdl.so.2 (0xb7f23000) libaa.so.1 => /usr/lib/libaa.so.1 (0xb7f09000) libcaca.so.0 => /usr/lib/libcaca.so.0 (0xb7f01000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7eed000) libc.so.6 => /lib/libc.so.6 (0xb7dce000) /lib/ld-linux.so.2 (0x80000000) libncurses.so.5 => /lib/libncurses.so.5 (0xb7d8c000) libX11.so.6 => /usr/lib/libX11.so.6 (0xb7ca0000) libgpm.so.1 => /lib/libgpm.so.1 (0xb7c9a000) libcucul.so.0 => /usr/lib/libcucul.so.0 (0xb7c1d000) libncursesw.so.5 => /lib/libncursesw.so.5 (0xb7bd1000) libstdc++.so.6 => /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libstdc++.so.6 (0xb7af0000) libgcc_s.so.1 => /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libgcc_s.so.1 (0xb7ae5000) libXau.so.6 => /usr/lib/libXau.so.6 (0xb7ae2000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb7add000) Do you see any errors? i don't :-) Well, but if i use "-d -r", ldd prints the following: # ldd -d -r /usr/lib/libSDL-1.2.so.0 linux-gate.so.1 => (0xb7fbd000) libm.so.6 => /lib/libm.so.6 (0xb7f25000) libdl.so.2 => /lib/libdl.so.2 (0xb7f21000) libaa.so.1 => /usr/lib/libaa.so.1 (0xb7f07000) libcaca.so.0 => /usr/lib/libcaca.so.0 (0xb7eff000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7eeb000) libc.so.6 => /lib/libc.so.6 (0xb7dcc000) /lib/ld-linux.so.2 (0x80000000) libncurses.so.5 => /lib/libncurses.so.5 (0xb7d8a000) libX11.so.6 => /usr/lib/libX11.so.6 (0xb7c9e000) libgpm.so.1 => /lib/libgpm.so.1 (0xb7c98000) libcucul.so.0 => /usr/lib/libcucul.so.0 (0xb7c1b000) libncursesw.so.5 => /lib/libncursesw.so.5 (0xb7bcf000) libstdc++.so.6 => /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libstdc++.so.6 (0xb7aee000) libgcc_s.so.1 => /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libgcc_s.so.1 (0xb7ae3000) libXau.so.6 => /usr/lib/libXau.so.6 (0xb7ae0000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb7adb000) undefined symbol: caca_end (/usr/lib/libSDL-1.2.so.0) undefined symbol: caca_refresh (/usr/lib/libSDL-1.2.so.0) undefined symbol: caca_get_width (/usr/lib/libSDL-1.2.so.0) undefined symbol: caca_draw_bitmap (/usr/lib/libSDL-1.2.so.0) undefined symbol: caca_init (/usr/lib/libSDL-1.2.so.0) undefined symbol: caca_get_height (/usr/lib/libSDL-1.2.so.0) undefined symbol: caca_create_bitmap (/usr/lib/libSDL-1.2.so.0) undefined symbol: caca_free_bitmap (/usr/lib/libSDL-1.2.so.0) It would be very terrific, if revdep-rebuild would use "-d -r" too. That might detect a lot of more possible problems. Reproducible: Always Steps to Reproduce:
Okay, I just implemented this into revdep-rebuild and it is not going to work. Using ldd -d -r generates way too many false positives. For example on my test system, using it wants to rebuild 85 packages. Of those 85 packages, the only one that is actually broken is libsdl. I can add it as an option to revdep-rebuild, but given this fact, I think it would be pretty useless for normal operations.
What are these false positives? What if you only use only "-r" ? Or can you send me the patch of revdep-rebuild? Then i could experiment a little by myself.
(In reply to comment #2) > What are these false positives? Well, zillions of them; this is absolutely not an option, tried this myself here.
Created attachment 107483 [details, diff] Patch to add ldd -d -r I've attached the patch that adds ldd -d -r to revdep-rebuild. You can play with it, but based upon my testing, I am not optimistic that this approach will work.
You're right. "-d" and "-r" don't make sense. Most of these false positives with undefined symbols where plugins - and of cause these undefined symbols are intensional. So how can we distinguish between plugins and normal binaries? Or more fine grained: how can we distinguish between intentionally undefined symbols and erroneous undefined symbols? We can't due to limitations by design. So i'm sorry for the noise and the time you wasted. Sorry! Small hope: "-d -r" is unsafe for libraries, but maybe it's safe for programs? (everything in /usr/bin etc.)
*** Bug 169251 has been marked as a duplicate of this bug. ***
*** Bug 155195 has been marked as a duplicate of this bug. ***
*** Bug 214399 has been marked as a duplicate of this bug. ***
Hello, continue from bug#214399 We must trust revdep-rebuild to correct system integrity. How can we provide users with sane system if our tools cannot find all inconsistencies? I had an issue with splashutils and OpenRC, I guess there will be more issues such as this as more and more libraries use ELF versioning and not just rename the library. This issue must be addressed, as users cannot test if each executable/configuration works by hand after each system update. Please reopen.
(In reply to comment #9) > Please reopen. Please, attach a patch that doesn't produce 99% of false positives, making the feature plain unusable. :)
Hello Jacub, Ignoring a problem does not provide a solution. We and our users have a real unsolved problem with system sanity, so we need to keep some bugs open, even if we don't have a solution. Having this as WONTFIX is not good publicity, also user may not find it. Now for this issue... I am not an expert in linkage. So I am not able to provide a solution alone. But I am thinking about the following procedure: Data gathering: 1. Export symbols using readelf --syms from all modules, divide this into two lists, one that list the imported symbols, and the other specifying the exported symbols. 2. For each module, create recursive dependency, for example a->b->c will become: a: b,c b: c Summary: For each module, load all symbols from recursive dependencies, shrink all imported symbols that have exported symbols. If left with exported symbols module is broken. What do you think?
If you feel that strongly, you are more than welcome to join the tools-portage team and fix the problem. To date, I have not seen a solution that works.
First we need to have an open issue, as it clearly an open issue with Gentoo. Next, I will try to invest some time in this after I finish my other tasks I am doing.
Reopening for a another look.
Created attachment 148048 [details, diff] ldd.patch Just for testing, I tried making revdep-rebuild use ldd -d -r for everything except *.so and *.so.* (problems in shared libraries will be detected when there's a program that links it in). It avoids the false positives with modules and plugins and works surprisingly well.
No false positives at my system. Did not have symbol breakage, I will report as soon as I get some. Thanks!
Created attachment 178002 [details, diff] revdep-rebuild-0.2.4.2-ldd.patch I too am trying to resolve dependency issues related to undefined symbols. I have adapted the patch that Harald proposed earlier to work against gentoolkit-0.2.4.2, and so far I have had no issues with false positives; as far as I know, revdep-rebuild has successfully located all of the broken packages related to the "d_gettext" symbol error that I have been having. My system is functional again; thank you.
*** This bug has been marked as a duplicate of bug 63643 ***
