| View previous topic :: View next topic |
| Author |
Message |
VoidMage
Watchman
Joined: 14 Oct 2006
Posts: 6196
|
 Posted: Wed Mar 06, 2013 11:13 pm Post subject: |
 |
|
@Navar: some people are unable to get even the obvious...
though your script should have worked...
Let's try a bigger hammer then:
| Code: | | find / -name 'libgtk-x11-2.0.so*' |
Stop playing with pkg-config though - all the available results show clearly that part is working properly.
Also, there unlikely to be a bug in the profiles - switching them most likely just toggles a useflag ('gtk', I'd say), which bypasses the problem by not building gtk ui for wireshark.
Minor correction: the gross incompetence of some of the people in this thread makes it easy to miss the important details.
Here, the important part was that revdep-rebuild output, more exactly the fact that those files aren't owned by portage.
vmvare installs a private copy of gtk+:2, however that copy isn't private enough for Gentoo.
Most likely this is the lib that gets detected by the macro.
As long as the copy is placed where the macro can find it, you'll be getting emerge failures with any package using the macro. |
|
| Back to top |
|
 |
Navar
Guru
Joined: 20 Aug 2012
Posts: 353
|
| Posted: Thu Mar 07, 2013 4:14 am Post subject: |
|
|
@eyoung100, to my limited knowledge, I don't recall PKG_CONFIG_PATH being set by default and isn't set anywhere here.
| voidmage wrote: | vmvare installs a private copy of gtk+:2, however that copy isn't private enough for Gentoo.
Most likely this is the lib that gets detected by the macro.
As long as the copy is placed where the macro can find it, you'll be getting emerge failures with any package using the macro. |
With all due respect, IF that be the case, it would have been useful to mention early on.  And if the case unmerge the sucker to resolve.  I'd also have expected it to be a long since ebuild resolved issue by now. They mask and ditch packages for less.
| voidmage wrote: | | Navar: some people are unable to get even the obvious... |
"No good deed goes unpunished..." I know... I know... I still tend to err on giving most people the benefit of doubt. But sometimes it unfortunately does take a club to get through thicker skulls. Speaking of which...
| eleanor wrote: | | Hi, If I remove the following files from /usr/lib64/ |
Really? You're offered this effective polished toolset and you greet us with, "I'm just going to gut it with a tweezers, hammer and saw instead and see what happens, cya." Tsk tsk. First, you're on a multilib profile. Note that link /usr/lib -> lib64. Same files as I had you list that are valid and relevant to gtk+-2.24.12 you guessed on removing. Why?... why... whywhywhywhy... must you muck about guessing? It must be time to plead to the Oracle:
| Code: | | while :;do echo why;sleep 0.1;done |
Furthermore, they're not even .so (as in shared objects) library files, which is the entire purpose for what revdep-rebuild is all about and why you're having issues on a configure phase. It'd be nice to get rid of all of your gtk+-2.24.10 install entirely, but focus on the basics that mattered for now.
| eleanor wrote: | | If I (then) try to install the wireshark, I get the error about gtk+ not being found: |
You don't say... Uh... wow... where to begin. A story in the long distant past about an executive who 'learned' how to delete whole registry keys and various files willy nilly from %systemroot% to 'fix' things? No no, a windows example is probably a horrible analogy but it sounds administratively hauntingly familiar. How about instead of using your perfectly good front door via a knock I just enter your home via a sledgehammer and a random exterior wall? Hm, no? Well you're no fun.  But neither is resolving this. Please let it sink in, for your sake.
| eleanor wrote: | | And then reemerging the gtk+-2.24.12 and then reemerging wireshark, I get the previous error: |
Because the only vector that changed was your re-emerge of that properly installed version of gtk+ replaced your tweezing out of its pkg-config .pc files that were installed. It changed and solved absolutely nothing other than putting back the wrong files to remove.
There are a lot of fun (sic) ways to go about resolving this. A basic one would be to simply equery f gtk+-2.24.12 >/tmp/filelist as a reference to what that ebuild installed for files (and you're so damned lucky to have that available) and let emerge -Cva =gtk+-2.24.12 or emerge -av --depclean =gtk+-2.24.12 to remove gtk+-2.24.12 cleanly. Then you can break out your tweezers, saw, and/or hammer as whatever you deem appropriate and go off looking for similar files to flush out your gtk+2.24.10 in your ldconfig troubles to resolve while guessing less. You can do it on a basic way via due and careful diligence using find, grep, and paying attention to timestamps. You can use /etc/ld.so.conf as your overall search path guide or truly hammer it with starting at /, either way. At this point I'm done playing detective Holmes on your setup. Please please, let some schmuck via a Google search and a blog misquote me here as yet another reason to avoid the distribution that is Gentoo. I can just hear it now. See! They suck at dealing with shared library issues.  So do idiots attempting to drive with loss of hydraulic/oil pressure.
When you feel you have accomplished that, particularly on related .so named files affiliated with gtk+2.24.10, then you can emerge wireshark, which by whatever global use flags set may pull in the valid gtk+-2.24.12 anyway instead of possibly parking it in your world file. You most likely will want wireshark with gtk.
| eleanor wrote: | I figured it out, and it was a total luck. Here are the needed commands to make it work:
I've set the dektop profile in the past, because someone recommended it (don't remember who though). |
Portage told you after a --sync. You were also asked to immediately upgrade portage first.
And it goes without saying, generally, that after doing those two you better have updated @world.
| eleanor wrote: | Two questions remain:
1. Is this a bug in the gentoo profile? Probably yes.
2. Why is using the desktop profile better than not using it? What's the difference?
I also think there's a bug in the hexchat, because this is displayed when I try to emerge it:
|
hexchat? Where where? Was it some of that 0xebadbeef padoor has been passing around?
1. Most definitely not and being foolhardy with assumptive assertions like that will eventually piss developers off. And then you may hear crickets, not 'hexchat'.
Almost everything mentioned here so far was in what has seemed a vain attempt to help you in standardized and well documented ways. The primary one rebelling against the boundaries set with the tools given has been you.
2. It's not 'better' per se, it just narrows down a subset of extra useflags added to the default rather than you needing to specify them. This is documented, and it's heavily searchable here as a repeated question in the forums. It used to (and probably still does) setup support for both kde and gnome instead of excluding one over the other, which can sometimes annoy--due to personal tastes. So, as was stated, you probably ditched "gtk" showing up in your useflags on emerge --info wireshark with your perceived 'fix'.
P.S., I know what you may be thinking. Actually I held back on cynicism.
_________________
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn. |
|
| Back to top |
|
|
VoidMage
Watchman
Joined: 14 Oct 2006
Posts: 6196
|
| Posted: Thu Mar 07, 2013 10:41 am Post subject: |
|
|
Well, that revdep-rebuild output suggests that instead of portage, a manual installation was used for vmware.
As far as those go, my first reaction is to associate them with actions like "use upstream installer for binary ati blob", that is "user is asking for trouble".
Unless the initial post makes it clear the user indeed went looking for trouble, I tend to test for common failures first and '/usr/local' one is far more common than 'upstream installer'. |
|
| Back to top |
|
|
eleanor
l33t
Joined: 01 Nov 2004
Posts: 666
|
| Posted: Fri Mar 08, 2013 4:34 pm Post subject: |
|
|
Hi, I solved the problem with the following commands:
| Code: |
# grep "2\.24\.10" /lib64/ -R
# mv /lib64/libgtk-x11-2.0.so* /backup/
# emerge wireshark
|
It works. Now it finds the right gtk. |
|
| Back to top |
|
|
Navar
Guru
Joined: 20 Aug 2012
Posts: 353
|
| Posted: Mon Mar 11, 2013 7:38 am Post subject: |
|
|
I hope others running into similar problems learn the 'right' things from this thread so it wasn't entirely for naught.
Eleanor,
Your command recursively searched inside of every file for the substring "2.24.10" within the /lib64/ path. I bet that took awhile, it's only about 50M of data here, probably more on your end. About 47K of data to search through on a full recursive file listing of same. What if it had been a current kernel version such as "3.7.10", can you imagine the spam of found results you'd have to sift through in a vain attempt to find your one file?
| Code: |
# time grep "3\.7\.10" /lib64/ -R | wc -l
426588
real 0m2.888s
user 0m2.045s
sys 0m0.871s
|
That's over 426588 results matched to wade through...
| Code: |
# time find / -name 'libgtk-x11-2*' -print
/usr/lib64/libgtk-x11-2.0.so.0
/usr/lib64/libgtk-x11-2.0.so.0.2400.12
/usr/lib64/libgtk-x11-2.0.so
real 0m0.580s
user 0m0.314s
sys 0m0.257s
|
That was the extreme and unnecessary case of the entire file system tree. That was the most inelegant a solution as you needed to use, but, while clearly stated, you still chose to ignore it.
Seriously, please read the man page on find. Hell, read up on grep too while you're there. Is there reasoning to what you do instead of following useful advice when it is given? 
_________________
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Desktop Environments
