On Wed, Aug 25, 2010, Wookey wrote: > I'm using amd64 - hopefully it doesn't matter.
Well I feared it might influence xdeb, since there is this bug about the need to use two caches; notably, I thought at least using a 32-bits build arch was better than a 64-bits for the visible package names. Now I don't expect it actually makes a big difference, but I wanted to mention it. > I'm a biut confused about this. I got this error in pdebuild-cross > because xapt was initially missing so the cross-deps simly weren't > being installed. As soon as they were installed then this part went > fine. Which is what I would expect. So there must be something > different about the environment in the xdeb case. I'll try and work > out what is going on. Is this on an Ubuntu host with an Ubuntu rootfs in your build environment? pbuilder doesn't cleanup the env, only debuild does. Also, dpkg-buildpackage used to set PKG_CONFIG_LIBDIR until recently, so if you're trying on an older distro (e.g. lucid) you might not see the issue we have now. > > Interestingly, the build broke because it couldn't find gtk-doc > > anymore; I didn't add /usr/share/pkgconfig, but it does show that host > > versus build pkg-config dependencies are a problem, and we need a > > $triplet-pkg-config to solve this! > > > > So I patched the gstreamer build to turn off docs; I think > > gstreamer0.10 should --disable-gtk-doc when cross-compiling; in fact, > > this should be done in gtk-doc upstream. > > I left docs on. It correspondingly pulls in a lot of deps (157 > cross-deps, but lots of them are null so it doesn't actually waste _too_ > much time). Nothing broke. Problems were not with the deps but with a call to pkg-config; I didn't have /usr/$triplet/share/pkgconfig in my path and I didn't cross gtk-doc to have it, but gtk-doc.pc was in /usr/share/pkgconfig, and it would probably have been picked up if I had bothered setting PKG_CONFIG_LIBDIR to pick it up. I thought the best fix here was actually to disable docs when cross-building because gtk-doc usually generates scanners and runs them, which obviously doens't work. > Yep. I think we can agree on that. It's interesting that the two build > methods don't quite give the same behaviour. I'll poke it some more to see > what's going on. I think I saw your error message later down, but I looked at the first error I got. -- Loïc Minier _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
