Bugzilla Bug 100012

Attempting to configure the new gconf-2.10.1, it errors out testing for  
pkg-config modules, due to looking for /usr/lib64/pkg-config/, while the actual  
dir is /usr/lib64/pkgconfig/ (no dash).  I don't know where the search-path is 
set, in the package or in another one, so I'm not sure the bug is even with 
this package, altho I haven't seen others with the problem (yet). 

Reproducible: Always
Steps to Reproduce:
emerge gconf-2.10.1 
Actual Results:  
configure errored out due to bad pkg-config path, as above. 

Expected Results:  
An uneventful merge. 

emerge info to be attached.

Created an attachment (id=64117) [details]
emerge info output

I just tried emerging it on my machine and did not get that error  

I almost forgot to post the relevant part of the output...  Thanks, Ben, for  
prodding me with your comment...  
  
--- tail end of the emerge log (reformatted slightly for posting here)...  
  
checking for pkg-config... /usr/bin/pkg-config  
  
checking for gmodule-2.0 >= 2.0.1 gobject-2.0 >= 2.0.1 ORBit-2.0 >= 2.4.0...   
  
Package gmodule-2.0 was not found in the pkg-config search path. Perhaps you  
should add the directory containing `gmodule-2.0.pc' to the PKG_CONFIG_PATH  
environment variable No package 'gmodule-2.0' found  
  
configure: error: Library requirements (gmodule-2.0 >= 2.0.1 gobject-2.0 >=  
2.0.1 ORBit-2.0 >= 2.4.0) not met; consider adjusting the PKG_CONFIG_PATH  
environment variable if your libraries are in a nonstandard prefix so  
pkg-config can find them.  
  
--- That portion of config.log (full file to be attached)  
configure:20322: checking for pkg-config  
configure:20340: found /usr/bin/pkg-config  
configure:20353: result: /usr/bin/pkg-config  
  
configure:20370: checking for gmodule-2.0 >= 2.0.1 gobject-2.0 >= 2.0.1  
ORBit-2.0 >= 2.4.0  
  
configure:20409: error: Library requirements (gmodule-2.0 >= 2.0.1 gobject-2.0  
>= 2.0.1 ORBit-2.0 >= 2.4.0) not met; co  
nsider adjusting the PKG_CONFIG_PATH environment variable if your libraries are  
in a nonstandard prefix so pkg-config c  
an find them. 
 
--- Trying the first of those --exists at the command line 
 
#export PKG_CONFIG_DEBUG_SPEW=1 
#pkg-config --exists gmodule-2.0 
 
PKG_CONFIG_DEBUG_SPEW variable enabling debug spew 
Adding directory '/usr/lib64/pkg-config' from PKG_CONFIG_PATH 
Adding directory '/usr/share/pkg-config' from PKG_CONFIG_PATH 
Global variable definition 'pc_top_builddir' = '$(top_builddir)' 
[snip] 
Adding virtual 'pkg-config' package to list of known packages 
Cannot open directory '/usr/lib64/pkg-config' in package search path: No such 
file or directory 
Cannot open directory '/usr/share/pkg-config' in package search path: No such 
file or directory 
Looking for package 'gmodule-2.0' 
Looking for package 'gmodule-2.0-uninstalled' 
Looking for 'gmodule-2.0' using legacy -config scripts 
Calling gnome-config 
Package gmodule-2.0 was not found in the pkg-config search path. 
Perhaps you should add the directory containing `gmodule-2.0.pc' 
to the PKG_CONFIG_PATH environment variable 
No package 'gmodule-2.0' found 
 
#ls -d /usr/lib64/pkg* 
 
/usr/lib64/pkgconfig/ 
 
--- Note that it added pkg-config, but the dir is pkgconfig. 
 
I should mention, as it's in my emerge.info, that I default to gcc-4.0.1.  
However, I tried gcc-config reverting to 3.4.4 (and yes, updating the 
environment) just in case that /somehow/ had something to do with it.  Same 
exact error. 
 

Created an attachment (id=64125) [details]
config.log

What version of pkgconfig ?

> Adding directory '/usr/lib64/pkg-config' from PKG_CONFIG_PATH

AFAIK the variable PKG_CONFIG_PATH is not set anywhere within portage, we rely
solely on the pkg-config compile time defaults at the moment. Do you have
PKG_CONFIG_PATH set in your environment somewhere?

(In reply to comment #6)   
> > Adding directory '/usr/lib64/pkg-config' from PKG_CONFIG_PATH   
>    
> Do you have PKG_CONFIG_PATH set in your environment somewhere?   
   
Good question!   
   
Not that I've deliberately set, no, and not in my general environment, either  
(I checked).  
    
I wondered about that too, and looked, but no such variable in my   
general environment, so it's not coming from there.  I there might be some sort  
of /etc/pkgconfig or whatever, as well, thinking that might be where it's  
coming from, but turned up nothing.  I don't know enough about pkg-config to  
be able to trace all the various potential sources, but the fact that it's 
wrong from the command line also, eliminates some potential sources, and the 
fact that it's not in my general shell environment eliminates others.  It's 
frustrating to see it saying it's pulling it out of that variable, see it's 
wrong as pulled out, but not be able to find where the variable's coming from!  
Maybe I'll have to do a grep of /usr and /etc for that string! 
 
Foser, pkg-config --version returns 0.18.1, and portage agrees. 
 
   
   
   
   

(In reply to comment #7) 
> (In reply to comment #6)    
> > > Adding directory '/usr/lib64/pkg-config' from PKG_CONFIG_PATH    
> >     
> > Do you have PKG_CONFIG_PATH set in your environment somewhere?    
>     
> Maybe I'll have to do a grep of /usr and /etc for that string!  
 
No file in /etc (or subdirs) contains the string "/usr/lib64/pkg-config". 
 
One file in /usr contains that string, the /usr/bin/pkg-config binary itself, 
line 163 (not that line numbers mean much in a binary, but...).  The binary 
contains a null, the variable, a null, the lib64 location, a colon, 
the /usr/share location also mentioned in the output, and another null, so this 
is almost certainly our culprit as that's exactly where it's searching.  It's 
compiled into pkg-config, so I guess that makes this now a pkg-config bug, not 
a gconf bug. 

  05 Jul 2005; Leonardo Boshell <leonardop@gentoo.org> pkgconfig-0.18.1.ebuild,
  files/pkg-config-0.18.1-pc_path.patch:
  Added patch from https://bugs.freedesktop.org/show_bug.cgi?id=3662 to set
  the default search path correctly.

Looks like this was fixed a while ago, though without a revision bump... (patch
was added same day as the 0.18.1 bump which is why it's not affected many
people) Please re-emerge pkgconfig which should fix this. Reopen if you still
have problems.

(In reply to comment #9) 
> Looks like this was fixed a while ago, though without a revision bump... 
(patch 
> was added same day as the 0.18.1 bump which is why it's not affected many 
> people) Please re-emerge pkgconfig which should fix this. Reopen if you still 
> have problems. 
 
Verified fixed.  I was in the process of filing a comment saying as much, when 
Bugzilla notified me of a collision!  Thanks!  (Full-closing.)