While cross-compiling, autotools fail to check xcb-proto version due to x11-proto/xcb-proto is DEPEND instead of RDEPEND. Reproducible: Always
Created attachment 309715 [details] Move >=x11-proto/xcb-proto-1.7-r1 from DEPEND to RDEPEND
It was recently changed to DEPEND due to bug 398953. Can you post your config.log/build.log?
In cross-compiling, RDEPEND install to $ROOT (build with cross compiler), DEPEND install to / (build with native compiler), so if we put >=x11-proto/xcb-proto-1.7-r1 in DEPEND, this kind of dependency won't fulfill what libxcb needs.
In native build, DEPEND => / RDEPEND => / PDEPEND => / In cross-compiling, DEPEND => / (with native toolchain, pkg-config search in /) RDEPEND => $ROOT (with cross toolchain, pkg-config search in $ROOT) PDEPEND => $ROOT (with cross toolchain, pkg-config search in $ROOT)
crossdev maintainers: is there a way to allow cross compiling while still reaching the goal of bug 398953?
Comment on attachment 309715 [details] Move >=x11-proto/xcb-proto-1.7-r1 from DEPEND to RDEPEND the current libxcb ebuild is correct. RDEPENDing on headers is wrong.
solar might be able to clarify, but iirc, this is what --root-deps=rdeps fixes
If I solve this kind of problem with --root-deps=rdeps, that will bring in a lot of hard to cross-compile build time dependencies and most of these packages I might never run on target device. I know put build dependencies in RDEPEND is not recommended, but it is most efficient way to solve this kind of problems. In fact, if I turn --root-deps=rdeps on, the number of packages emerging in stage 3 will increase from 51 to 113, some packages been brought in like gcc, perl are hard to cross-compile to me.
(In reply to comment #8) > If I solve this kind of problem with --root-deps=rdeps, that will bring in a > lot of hard to cross-compile build time dependencies and most of these > packages I might never run on target device. RDEPEND should only contain things that are needed at run-time. If it's not needed at run-time, file a bug for the ebuild maintainer to remove it from RDEPEND. > I know put build dependencies in RDEPEND is not recommended, but it is most > efficient way to solve this kind of problems. In fact, if I turn > --root-deps=rdeps on, the number of packages emerging in stage 3 will > increase from 51 to 113, some packages been brought in like gcc, perl are > hard to cross-compile to me. What you describe here sounds like --root-deps (which pulls DEPEND into $ROOT). With --root-deps=rdeps, DEPEND is supposed to be discarded competely.
With --root-deps=rdeps, DEPEND => $ROOT. With --root-deps, DEPEND => /. This is me experience. No dependencies discarded I think.
(In reply to comment #10) > With --root-deps=rdeps, DEPEND => $ROOT. > > With --root-deps, DEPEND => /. > > This is me experience. No dependencies discarded I think. That's not how it's supposed to work. Note edepend["DEPEND"] = "" in the relevant code from /usr/lib/portage/pym/_emerge/depgraph.py is: if removal_action: depend_root = myroot else: depend_root = self._frozen_config._running_root.root root_deps = self._frozen_config.myopts.get("--root-deps") if root_deps is not None: if root_deps is True: depend_root = myroot elif root_deps == "rdeps": ignore_build_time_deps = True # If rebuild mode is not enabled, it's safe to discard ignored # build-time dependencies. If you want these deps to be traversed # in "complete" mode then you need to specify --with-bdeps=y. if ignore_build_time_deps and \ not self._rebuild.rebuild: edepend["DEPEND"] = ""
If --root-deps discards DEPENDs, how portage to handle this: a DEPEND b but b not install yet, terminate immediately? In fact, there are some packages check their DEPEND with pkg-config (which means search in $ROOT, not /). What I exact need to know is how can I handle this kind of packages, a solution you guys think it's OK and efficient enough to me and I will apply to these packages.
(In reply to comment #12) > If --root-deps discards DEPENDs, how portage to handle this: a DEPEND b but > b not install yet, terminate immediately? It's not supposed to handle that. For Chromium OS, they use a hard-host-depends package to handle it: http://www.chromium.org/chromium-os/how-tos-and-troubleshooting/portage-build-faq#TOC-How-does-the-cross-compiling-setup-work- > In fact, there are some packages check their DEPEND with pkg-config (which > means search in $ROOT, not /). What I exact need to know is how can I handle > this kind of packages, a solution you guys think it's OK and efficient > enough to me and I will apply to these packages. I don't know, because that's low-level stuff that portage doesn't deal with directly.
Thanks Zac, Chromium OS way is right and clean way. But it also a harder way to me. Currently, I have no idea how to balance.
I have solved this kind of issues by wrapper scripts for pkg-config and emerge. pkg-config wrapper called by configure, if build failed, it knows which .pc is required by built package, then emerge wrapper try to install the owner packages of .pc files, then emerge --resume.
*** This bug has been marked as a duplicate of bug 415209 ***
