Created attachment 677302 [details] emerge --info.txt nss fails on crossdev host compiling for amd64
Created attachment 677305 [details] build.log
Wondering if https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-libs/nss/nss-3.59-r1.ebuild?id=d3f2cba10c86d044abad85e9b00b539e365eca8f#n72 is not firing for you...
CBUILD didn't have nss at all so... not sure if that sed would've helped.
sorry I forgot to mention this, but installing nss on CBUILD fixes the problem. There definitely needs to be a way to tell portage that some packages want themselves to be present in BDEPEND on CBUILD.
Hrmm, I just ran into this as well. ``` shlibsign -v -i /build/arm64-generic/tmp/portage/dev-libs/nss-3.68.2-r3/work/nss-3.68.2/nss-.arm64/cmd/shlibsign/../../dist/Linux6.1_aarch64_clang_glibc_PTH_64_OPT.OBJ/lib/libsoftokn3.so /build/arm64-generic/tmp/portage/dev-libs/nss-3.68.2-r3/work/nss-3.68.2/nss-.arm64/cmd/shlibsign/./sign.sh: line 37: shlibsign: command not found ``` I would add `BDEPEND+=" dev-libs/nss"` to the ebuild, but this dependency only applies when cross compiling... I wonder what the correct way to handle this is. Should we add a new `USE` flag `cross-compile` that portage will set when the CBUILD != CHOST? Then we could do `BDEPEND+=" cross-compile? ( dev-libs/nss )"`.
If anyone was curious, this is the hack I put in place in our (chromiumos) build system: https://chromium-review.googlesource.com/c/chromiumos/bazel/+/4655206
this isn't a situation for USE flags. packages can use `tc-is-cross-compiler` to determine on the fly whether they should build their own copy of local tools. some packages already do this. some will cheat and see if the tools are already available in $PATH and are recent/compatible, and if so, use them, otherwise fallback to building a copy from the sources and adding those to their $PATH.
(In reply to SpanKY from comment #7) > this isn't a situation for USE flags. packages can use > `tc-is-cross-compiler` to determine on the fly whether they should build > their own copy of local tools. some packages already do this. some will > cheat and see if the tools are already available in $PATH and are > recent/compatible, and if so, use them, otherwise fallback to building a > copy from the sources and adding those to their $PATH. If you have a setup with crosscompile available, could you write the update and commit? I can't test it easily and don't like to guess whether I got it right or not. I do see examples you mentioned of, though to take note.
