Maybe this should not be a bug, but could you please explain why cross-emerge unconditionally passes --root-deps=rdeps to emerge? This is causing several build errors as I try to do a cross-emerge -ea1v @system. Refer to the following to bugs below illustrating why this is a problem. https://bugs.gentoo.org/654026 https://bugs.gentoo.org/653942 The following excerpt from https://wiki.gentoo.org/wiki/Embedded_Handbook/General/Cross-compiling_with_Portage does not really explain what is the benefit/reasoning of not pulling in host dependencies: By default these wrappers use the --root-deps=rdeps option to avoid the host dependencies from being pulled into the deptree. This can lead to incomplete deptrees. Therefore you may want to use --root-deps alone to see the full depgraph. In my case, I am trying to build a brand new system from scratch using crossdev as follows: 1.Create cross toolcain (crossdev -t armv7a-pip-linux-gnueabi) 2.Unpack latest portage snapshot into /usr/armv7a-pip-linux-gnueabi/usr 3.Update /usr/armv7a-pip-linux-gnueabi/etc/portage/make.profile symlink to point to ../../usr/portage/profiles/default/linux/arm/13.0/armv7a 4. sudo armv7a-pip-linux-gnueabi-emerge -a1v --noreplace --keep-going @system 5. repeat step 4 as necessary until emerge has built a complete system 6. Build an image from the cross-root and install on target system I actually have successfully installed over 100 of the 134 packages in @system. And now several of the bugs I am running into are related to missing build dependencies. Is the goal of --root-deps=rdeps to try to avoid installing non-runtime dependencies in the cross-root (to save space on the presumably embedded target). In that case, wouldn't the way to accomplish that correctly be to build witout --root-deps=rdeps....then do emerge --depclean to remove packages that were only there as build deps and not rdeps?
I just found this about HDEPEND: https://dev.gentoo.org/~zmedico/portage/doc/ch06s03s10.html#package-ebuild-eapi-5-hdepend-metadata-dependencies-targetroot I am still not clear on how a package could be successfully build if a build dependency is only installed on the build machine and and not the target. In the systemd bug linked in https://bugs.gentoo.org/654032#c0 the latest failure seems to be because sys-util/linux is not installed on the target (it definitely is on the build machine). systemd lists util-linux as both an RDEPEND and and DEPEND. It does not have any HDEPEND. Is the thinking that once the package is updated to separate DEPEND into HDEPEND and DEPEND that it will also change the build so that it will use packages on the build machine listed in HDEPEND rather than expect them to be on the target?
--root-deps=rdeps is a hack to avoid pulling in too many things into ROOT like pkg-config, gcc and the like. It's not a clean solution. EAPI=7 will provide more fine-grained way to distinct between build-deps that should be present in on native system (--build in autotools land) and SYSROOT (--host in autotools land): - BDEPEND= -> / - DEPEND= -> SYSROOT https://wiki.gentoo.org/wiki/Future_EAPI/EAPI_7_tentative_features#Enhancements_of_existing_features This will need gradually updating many ebuilds.
This is exactly the information I was looking for. Thanks! *** This bug has been marked as a duplicate of bug 317337 ***
(In reply to Sergei Trofimovich from comment #2) > --root-deps=rdeps is a hack to avoid pulling in too many things into ROOT > like pkg-config, gcc and the like. It's not a clean solution. > > EAPI=7 will provide more fine-grained way to distinct between build-deps > that should be present in on native system (--build in autotools land) and > SYSROOT (--host in autotools land): > - BDEPEND= -> / > - DEPEND= -> SYSROOT > > https://wiki.gentoo.org/wiki/Future_EAPI/ > EAPI_7_tentative_features#Enhancements_of_existing_features > > This will need gradually updating many ebuilds. I just noticed gcc is one of the examples you gave of a host build dep. Actually in my cases since I have not yet successfully installed gcc in the sysroot I cannot boot. The kernel boots up fine. But /lib/systemd/systemd can't execute becuase it has a library dependency on libgcc_s.so, which is provided by gcc. I checked and many (but not all) libraries in the sysroot need libgcc_s.so.1. Is this expected?
(In reply to Joe Harvell from comment #4) > (In reply to Sergei Trofimovich from comment #2) > > --root-deps=rdeps is a hack to avoid pulling in too many things into ROOT > > like pkg-config, gcc and the like. It's not a clean solution. > > > > EAPI=7 will provide more fine-grained way to distinct between build-deps > > that should be present in on native system (--build in autotools land) and > > SYSROOT (--host in autotools land): > > - BDEPEND= -> / > > - DEPEND= -> SYSROOT > > > > https://wiki.gentoo.org/wiki/Future_EAPI/ > > EAPI_7_tentative_features#Enhancements_of_existing_features > > > > This will need gradually updating many ebuilds. > > I just noticed gcc is one of the examples you gave of a host build dep. > Actually in my cases since I have not yet successfully installed gcc in the > sysroot I cannot boot. The kernel boots up fine. But /lib/systemd/systemd > can't execute becuase it has a library dependency on libgcc_s.so, which is > provided by gcc. I checked and many (but not all) libraries in the sysroot > need libgcc_s.so.1. Is this expected? Yes, it is expected (and unfortunate) to miss a few gcc bits on target. Gentoo has no separate ebuilds (or special handling) yet for: libgcc_s, libstdc++ and other stuff bundled with gcc. One has either copy those manually or install gcc into target.
