| Summary: | gtk+-2.18.5 claims to need DirectFB-1.2.0.so.0 when DirectFB-1.4.x is installed and the other way around | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Attila Stehr <as.gentoo> |
| Component: | New packages | Assignee: | PMS/EAPI <pms> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | normal | CC: | esigra, galtgendo, themazepa, tools-portage |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 192319 | ||
| Bug Blocks: | |||
| Attachments: |
build log of gtk+-2.18.5
emerge --info gtk-query-immodules-2.0 script |
||
|
Description
Attila Stehr
2010-01-13 17:23:35 UTC
A revdep-rebuild problem or IOW INVALID. revdep-rebuild Actually that happens when executing revdep rebuild. What's below I tried to fix it but it happend too! Certain forum posts lead me to believe that either revdep-rebuild doesn't get the order right in this case or one of the libs in gtk+ stack has a missing dep. Well, that or it's la file pollution again. Well, there's a *minor* chance it's something else, but to be able to tell, a full build log (and a few more things) would be needed. Created attachment 216431 [details]
build log of gtk+-2.18.5
What's the "few other whings"?
Created attachment 216432 [details]
emerge --info
Well, in /var/tmp/portage/x11-libs/gtk+-2.18.5/work/gtk+-2.18.5/gtk/ there should be 'gtk-query-immodules-2.0', not the real executable, but a libtool wrapper script. Could you attach it ? But first, go into /var/tmp/portage/x11-libs/gtk+-2.18.5/work/gtk+-2.18.5/gtk/.libs/ and see if ldd run on the freshly built gtk libs returns only libdirectfb-1.4.so.0, not libdirectfb-1.2.so.0. Created attachment 216436 [details]
gtk-query-immodules-2.0 script
ldd libgtk-x11-2.0.so | grep -i libdirectfb
libdirectfb-1.4.so.0 => /usr/lib/libdirectfb-1.4.so.0 (0x00007fe573179000)
libdirectfb-1.2.so.0 => not found
ldd libgtk-x11-2.0.so.0 | grep -i libdirectfb
libdirectfb-1.4.so.0 => /usr/lib/libdirectfb-1.4.so.0 (0x00007f6f31a07000)
libdirectfb-1.2.so.0 => not found
ldd libgtk-x11-2.0.so.0.1800.5 | grep -i libdirectfb
libdirectfb-1.4.so.0 => /usr/lib/libdirectfb-1.4.so.0 (0x00007f6dd1583000)
libdirectfb-1.2.so.0 => not found
grep doesn't tell much. Take LD_LIBRARY_PATH value from that script and run it against that freshly binary as LD_LIBRARY_PATH=<that value> ldd <that new binary> But first try simply to rebuild cairo and pango first. > But first try simply to rebuild cairo and pango first.
That fixed it. Thanks!
PLease close the bug if there's nothing to do w/ the ebuild or whatever.
Well, now I disagree. This was reported a few times too many on the forums to be a coincidence or a simple user error. It seems that there's either a problem with revdep-rebuild or it's la file pollution again. However I'm not sure, whom to assign this bug to. lets try the portage team :) I guess 203480 may just have the same reason here so I hope it's okay that I added you to the CC list there. Bug 203480 is obviously completely unrelated to this one. portage doesnt deal in revdep-rebuild nor broken binaries. la file pollution would not cause the errors you're seeing. ldd also doesnt paint a useful picture. use lddtree on the broken binary to figure out what package you need to re-emerge. My point is that people in those forum posts claimed that the problem happens during revdep-rebuild. That means that for some reason order of rebuild is wrong. Please have a look at #203480 again. The solution was to execute the emerge command "calculated" by revdep-rebuild _manually_ since revdep-rebuild doesn't do that. (In reply to comment #18) > My point is that people in those forum posts claimed > that the problem happens during revdep-rebuild. > > That means that for some reason order of rebuild is wrong. I claim that too! Please have a look at comment #3. (I put this comment here for everyone but Rafal and me.) I think dev-portage is the right address after all. As it happened to many times to be random, it's probably reordering of dependencies that gets something wrong. As cairo/pango rebuild solved it, this should be the place, were something went wrong. (and I'm still not excluding la file pollution, though it may just be something like pango/cairo getting injected into world) (In reply to comment #21) > As cairo/pango rebuild solved it, this should be the place, were something > went wrong. If packages need to be forced to be rebuilt then maybe it's something like bug 192319. this happened to me during r-r as well. rebuilding of cairo and pango fixed it for me as well. I have what looks related in coming from DirectFB-1.0.0 to 1.4.x
emerge grip ....
grip
grip: error while loading shared libraries: libdirectfb-1.0.so.0: cannot open shared object file: No such file or directory
lddtree `which grip`
...
libcairo.so.2 => /usr/lib/libcairo.so.2
libpixman-1.so.0 => /usr/lib/libpixman-1.so.0
libdirectfb-1.4.so.0 => /usr/lib/libdirectfb-1.4.so.0
libfusion-1.4.so.0 => /usr/lib/libfusion-1.4.so.0
libdirect-1.4.so.0 => /usr/lib/libdirect-1.4.so.0
libglitz-glx.so.1 => /usr/lib/libglitz-glx.so.1
...
smells like .la cruft to me.
Any explanation? Seems like the same root cause , perhaps this info with help triangulate.
DirectFB is gone. |
