When emerging libxcb, the configure step fails because xcb-proto isn't installed. This only happened to me when building on a crossdev environment using the embedded profile. After I emerged xcb-proto the build succeeded. I guess some other ebuild in other profiles automatically brings in xcb-proto so this isn't an issue for most people. Reproducible: Always Steps to Reproduce: 1. Create an empty crossdev environment with the embedded profile. 2. emerge libxcb
I actually just looked at the ebuild and it seems to depend on xcb-proto but there's still a weird problem. If I unmerge xcb-proto and libxcb and try to run emerge-arm-omap3-linux-gnueabi -p libxcb, it does not try to install xcb-proto. This could actually be a bug in the crossdev wrappers or something else. I also get the same problem with: libX11 and xextproto libXxf86vm and xf86vidmodeproto
(In reply to comment #1) > If I unmerge xcb-proto and libxcb and try to run emerge-arm-omap3-linux-gnueabi > -p libxcb, it does not try to install xcb-proto. Do this again with --debug added and attach the output.
Created attachment 205431 [details] emerge-arm-omap3-linux-gnueabi -pv1 --debug libxcb I got this using: emerge-arm-omap3-linux-gnueabi -pv1 --debug libxcb > 'emerge-libxcb.log'
It only considers runtime dependencies. Please attach this emerge wrapper.
I have sys-devel/crossdev-wrappers-20090922 installed. That is what I'm using. It's actually a slightly complicated set of scripts, not just one. The cross-emerge script that comes with that seems to be the script that adds the --root-deps=rdeps option. I tried disabling that option by adding --root-deps=True and it results in emerge bringing in in lots of unnecessary stuff for embedded projects that exist in the host's root (automake, eselect, libtool, and python are some examples). Also, I looked at the contents of the xcb-proto package and it's not architecture-specific. I'm not that well informed on this matter but maybe the ebuild needs to find some way to use the xcb-proto installed on the host for packages like this (like what it does for compilers, automake, make, etc).
The problem is, that you want only some of it's build time dependencies installed. You want xcb-proto but not libtool and the other stuff. I don't think there is another way than installing the "really" need deps by hand.
What if you add the --with-bdeps=y option to emerge?
(In reply to comment #7) > What if you add the --with-bdeps=y option to emerge? > I tried this and it does not try to emerge xcb-proto. The more I think about it, the issue might be with the pkg-config wrapper included with crossdev-wrappers. As mentioned before, xcb-proto is platform-independent so what might be needed in these cases is to allow the pkg-config wrapper that comes with crossdev-wrappers to use the host system's xcb-proto (and other known cross-platform build-only packages) and everything should work. I should probably post something about this in the gentoo embedded mailing list.
Perhaps the maintainer can add a helpful comment.
except that xcb-proto is not installing its pc file into the site-independent directory (/usr/share/pkgconfig/) therefore it is by definition site-dependent whether xcb-proto is broken in this matter is up to the X11 guys ... pkg-config is operating correctly in this situation
There's a wide project upstream to move all the X .pc files into /usr/share (instead of /usr/lib) where it makes sense. So far, only the "old" protocol headers have been mentioned. I'll try to make sure xcb-proto gets the same treatment. Thanks
crossdev-wrappers (cross-fix-root) should handle both usr/lib/pkgconfig/*.pc usr/share/pkgconfig/*.pc files fine.
ok, assuming the .pc files are fixed in the normal line of things. that leaves the bdeps issue which afaik isnt specific to libxcb nor any package. this is the discussion (another bug open already?) where we dont differentiate between packages that are needed on the build host (autotools/make/etc...) and packages that are needed for the target, but only to compile (all the X11 proto packages that install headers). i dont think there is a clean workaround for this. you could work around it obviously by just installing all the proto packages yourself.
(In reply to comment #13) > i dont think there is a clean workaround for this. you could work around it > obviously by just installing all the proto packages yourself. Our current plan is to pull the proto packages from the corresponding lib package in both DEPEND and RDEPEND, since there's no satisfying way of defining this sort of deps with current EAPIs. That means that binary package users will get proto packages installed, but I was told embedded folks tend to do manual clean-ups of /usr/include and other dirs when creating images. Let me know if that's ok with you and I'll work on it sooner rather than later :) Cheers
since most library packages include headers in the same package and there's no way to split them, embedded installs will (must?) strip /usr/include/ and similar paths. so the proto packages would get culled in this process. so adding the dep sounds fine to me ... might want to make sure to add a little note in the ebuild as to why otherwise i imagine people will whine/file bugs to get the change reverted.
*** Bug 371545 has been marked as a duplicate of this bug. ***
purged from portage
