Hello, I try to explain this as well as I can, feel free to ask questions and I'll do my best to clarify. Starting with commit 03f1639 ("sys-libs/libxcrypt: general clean up"), a breakage was introduced for systems where CHOST != CTARGET because of this new line: "local CHOST=${CTARGET}". Inspecting the default Gentoo toolchains and crossdev setup (eg by debugging aarch64-unknown-linux-gnu-emerge sys-libs/libxcrypt), I notice: CHOST = aarch64-unknown-linux-gnu CTARGET = aarch64-unknown-linux-gnu so the CHOST=${CTARGET} line is a NO-OP, in other words the same tools get called as before the commit, like for example aarch64-unknown-linux-gnu-pkg-config (symlinked from crossdev's cross-pkg-config). Other toolchains, like the ChromiumOS toolchain, set CHOST != CTARGET so one gets values like the following: CHOST = x86_64-pc-linux-gnu CTARGET = aarch64-cros-linux-gnu Thus the newly added CHOST=${CTARGET} line causes a different set of tools to be invoked by configure (eg aarch64-cros-linux-gnu-pkg-config instead of x86_64-pc-linux-gnu-pkg-config). This causes breakage because the crossdev versions, like aarch64-cros-linux-gnu-pkg-config symlinked to the cross-pkg-config script, in turn call the unprefixed pkg-config [1] instead of the properly prefixed tools (eg x86_64-pc-linux-gnu-pkg-config). The breakage is caused by my profile containing a check which strictly prohibits calling unprefixed tools like this pkg-config while cross compiling. Before libxcrypt-4.4.36-r3 it was ok because configure called x86_64-pc-linux-gnu-pkg-config directly. I have created a PR with a simple solution of bringing back the old behaviour: https://github.com/gentoo/gentoo/pull/40337 If that is not acceptable maybe we can find another, eg. to add a use flag to allow CHOST != CTARGET? [1] https://gitweb.gentoo.org/proj/crossdev.git/tree/wrappers/cross-pkg-config#n135 Reproducible: Always Steps to Reproduce: 1. Build libxcrypt-4.4.36-r3 with a CHOST != CTARGET toolchain 2. Notice how instead of calling ${CHOST}-pkg-config, libxcrypt now ends up calling the unprefixed pkg-config via cross-pkg-config. Actual Results: My profile check fails the build because an unprefixed "pkg-config" gets called instead of the expected ${CHOST}-pkg-config. Expected Results: I expect the libxcrypt-4.4.36-r3 build to respect the CHOST setting and call the properly prefixed pkg-config.
Calling ${CHOST}-pkg-config is simply wrong in the scenario. We want to call the cross-pkg-config wrapper (or an appropriate ${CTARGET-pkg-config binary) so that SYSROOT gets added to PKG_CONFIG_PATH, etc. The problem here is with your profile, which is breaking the cross-pkg-config script. I think we should focus on how to make that work.
I'm confused. CTARGET is rarely used and when it is, it always involves crossdev. crossdev doesn't handle this package though, so what is this code even for? In any case, having the wrapper call "${CBUILD}{CBUILD+-}pkg-config" rather than "pkg-config" seems like a reasonable compromise.
CTARGET gets set to ${tuple} when you install cross-${tuple}/libcrypt. It's like installing cross-${tuple}/glibc or cross-${tuple}/musl. We set that up to allow libxcrypt to be installed as part of bootstrapping a crossdev environment rather than installing it after the crossdev environment has already been established. https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=aabea35bb6fdc0e5de5b899c0c2efa8e9570b1e1 It's really kind of an abuse of ${CTARGET} since we are not building a compiler here, and that's why the ebuild ends up copying it to ${CHOST}.
(In reply to James Le Cuirot from comment #2) > In any case, having the wrapper call "${CBUILD}{CBUILD+-}pkg-config" rather > than "pkg-config" seems like a reasonable compromise. I like that idea.
PR filed. Please review.
Thank you, I tested the patch and it solves my unprefixed pkg-config problem.
Approved. (In reply to Mike Gilbert from comment #3) > CTARGET gets set to ${tuple} when you install cross-${tuple}/libcrypt. It's > like installing cross-${tuple}/glibc or cross-${tuple}/musl. I get that, but when do we actually do that? There's no reference to libxcrypt in crossdev at all and cross-${tuple} symlinks don't get created by anything else?
Not sure how the symlink gets created. Perhaps Adrian is using a fork of crossdev?
Ah, it looks like ChromiumOS uses the --ex-pkg option to install it. https://chromium.googlesource.com/chromiumos/overlays/toolchains/+/refs/heads/main/README.md
Yes, I'm using the --ex-pkg option and I'm also the one who added the "headers-only" USE flag to the libxcrypt ebuild because otherwise I couldn't bootstrap the ChromeOS LLVM compiler due to a circular dependency (I needed libxcrypt early in the toolchain bootstrap process).
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/crossdev.git/commit/?id=15280e942a3f6490c62b2978e0b951f9cbb9066d commit 15280e942a3f6490c62b2978e0b951f9cbb9066d Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2025-01-28 17:09:02 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2025-01-28 17:11:14 +0000 cross-pkg-config: call ${CBUILD}-pkg-config when available This avoids calling plain pkg-config in environments where that binary has been blacklisted. Bug: https://bugs.gentoo.org/948948 Signed-off-by: Mike Gilbert <floppym@gentoo.org> wrappers/cross-pkg-config | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-)
