I use Gentoo Linux and I love it however the Portage package manager can be confusing sometimes with all the USE flags and other variables which can be set. Generally the error messages are fairly accurate with instructions however today I ran across a particularly stubborn package that just would not build.
The package was x11-apps/xdpyinfo. Now I have never had a problem with this package before so it had me pretty stumped. So I took a look at the build log and noticed that XTest.h was the problem.
make[1]: Entering directory `/var/tmp/portage/x11-apps/xdpyinfo-1.1.0/work/xdpyinfo-1.1.0'
GEN xdpyinfo.1
CC xdpyinfo.o
xdpyinfo.c:94:34: error: X11/extensions/XTest.h: No such file or directory
xdpyinfo.c: In function 'print_xtest_info':
xdpyinfo.c:701: warning: implicit declaration of function 'XTestQueryExtension'
xdpyinfo.c:701: warning: nested extern declaration of 'XTestQueryExtension'
xdpyinfo.c: At top level:
xdpyinfo.c:1485: error: 'XTestExtensionName' undeclared here (not in a function)
make[1]: *** [xdpyinfo.o] Error 1
make[1]: Leaving directory `/var/tmp/portage/x11-apps/xdpyinfo-1.1.0/work/xdpyinfo-1.1.0'
make: *** [all] Error 2
*
* ERROR: x11-apps/xdpyinfo-1.1.0 failed.
* Call stack:
* ebuild.sh, line 49: Called src_compile
* environment, line 3212: Called x-modular_src_compile
* environment, line 3997: Called x-modular_src_make
* environment, line 4036: Called die
* The specific snippet of code:
* emake || die "emake failed"
* The die message:
* emake failed
So just a quick little trick you can do if this happens to you is use equery to find out which package in Portage contains that one file you need.
r00t@infected ~/Downloads $ equery b /usr/include/X11/extensions/XTest.h [ Searching for file(s) /usr/include/X11/extensions/XTest.h in *... ] !!! Parse error in '/var/db/pkg/dev-libs/check-0.9.5-r1/CONTENTS' !!! line 1: Null byte found in CONTENTS entry x11-proto/xextproto-7.0.5 (/usr/include/X11/extensions/XTest.h) r00t@infected ~/Downloads $
Now all you need to do is emerge whichever package your file belonged to and you should be able to build the one that was giving you trouble.
Thanks very much for this post. I had the same problem (in fact, numerous packages were failing to merge due to this). My case was slightly different, but your tip really helped me solve it:
At some point I had bumped libXext to the unstable 1.1.1, which in turn had bumped xextproto to 7.1.1, which no longer includes XTest.h, this mean that:
equery b /usr/include/X11/extensions/XTest.h
Did not return any packages, presumably because it searches the packages that would be pulled into the ordinary portage tree. Looking at the man page I couldn’t find a way to make equery look at manifests for all package versions. Once I removed the offending keywords that were unmasking the *.1.1 versions,
equery b X11/extensions/XTest.h
did return the correct files (note that it seems equery is happy with the relative path as given in build error).
Regardless, downgrading to libXext-1.0.5 and xextproto-7.0.5 restored XTest.h and seems to have made the various other packages happy. (Note: I temporarily removed libXext completely to get round blocks in downgrading xextproto).
Interested to hear of a way to query package ownership of files across all versions. Thanks again for the tip.