Hello I'm creating cross-* packages for libxcrypt by passing --ex-pkg to crossdev. In the libxcrypt-4.4.36.ebuild, there was this logic for handling CC and everything worked fine ``` if is_cross; then if tc-is-clang; then export CC="${CTARGET}-clang" else export CC="${CTARGET}-gcc" fi fi ``` The libxcrypt-4.4.36-r3.ebuild reworked the cross logic, so CC gets unset then tc-getCC makes it default to gcc: ``` if target_is_not_host; then local CHOST=${CTARGET} MYPREFIX= MYSYSROOT=${ESYSROOT}/usr/${CTARGET} # Ensure we get compatible libdir unset DEFAULT_ABI MULTILIB_ABIS multilib_env ABI=${DEFAULT_ABI} tc-getCC >/dev/null if [[ ${CC} != ${CHOST}-* ]]; then unset CC tc-getCC >/dev/null fi strip-unsupported-flags fi ``` This is a problem because I want to use clang. For example, just before the CHOST=${CTARGET} line, when building a cross-aarch64-cros-linux-gnu/libxcrypt, my vars are: CBUILD=x86_64-pc-linux-gnu CHOST=x86_64-pc-linux-gnu CTARGET=aarch64-cros-linux-gnu CC=x86_64-pc-linux-gnu-clang Can we please find a way to fix this so CC gets correctly set to ${CTARGET}-clang like it used to before -r3 of the ebuild? Reproducible: Always Steps to Reproduce: 1. Build cross-* versions of and libxcrypt-4.4.36.ebuild libxcrypt-4.4.36-r3.ebuild 2. Compare the values of CC Actual Results: CC changes between 4.4.36 and 4.4.36-r3, it is not set to ${CTARGET}-clang anymore, actually defaults to GCC :) Expected Results: I'd expect CC=${CTARGET}-clang like in 4.4.36
Sorry for the trouble and thanks for the report. The original logic is flawed in that using clang for CHOST does not necessarily imply that we should use clang for CTARGET as well. That fits your use case, but it might not work for everyone. Maybe we could wire up TARGET_CC as an override, and default to the old behavior.
Does this work for you? https://github.com/gentoo/gentoo/pull/40662
Thank you, I just verified and approved the PR.
I'm curious why the use of CTARGET in the ebuild at all. CTARGET is normally used when building the compiler so you can specify the target architecture of the compiler. `libxcrypt` is just a package that will be used to link against by other things that use the compiler sysroot. Conceptually this is what I would expect: Building cross-arm-unknown-linux-gnu/gcc: CBUILD=x86_64-pc-linux-gnu CHOST=x86_64-pc-linux-gnu CTARGET=arm-unknown-linux-gnu D=${ESYSROOT}/usr/${CTARGET} Building cross-arm-unknown-linux-gnu/libxcrypt: CBUILD=x86_64-pc-linux-gnu CHOST=arm-unknown-linux-gnu CTARGET=<none> D=${ESYSROOT}/usr/${CHOST}
If you want to do that, then just do arm-unknown-linux-gnu-emerge libxcrypt. I almost suggested that before, but I thought I might be missing something.
Untested theory: We might be able to get away with doing just a USE=headers-only libxcrypt build when bootstrapping the LLVM cross- compilers, thus avoiding the need to depend on CTARGET (and the CC value becomes irrelevant), then later we could do normal arm-unknown-linux-gnu-emerge libxcrypt builds like James & Raul suggest. I will test this theory tomorrow and report back. Can't remember exactly where in the LLVM bootstrap process I needed libxcrypt (definitely needed the headers very early, unsure about the actual lib).
I wasn't necessarily suggesting `arm-unknown-linux-gnu-emerge libxcrypt`. I feel like that makes it hard to declare dependencies correctly. I was more questioning the following logic: https://github.com/gentoo/gentoo/blob/master/eclass/crossdev.eclass#L56-L63 ``` # Default CBUILD and CTARGET to CHOST if unset. export CBUILD=${CBUILD:-${CHOST}} export CTARGET=${CTARGET:-${CHOST}} if [[ ${CTARGET} == ${CHOST} ]] ; then # cross-aarch64-gentoo-linux-musl -> aarch64-gentoo-linux-musl [[ ${_IS_CROSSPKG} == 1 ]] && export CTARGET=${CATEGORY#${_CROSS_CATEGORY_PREFIX}} fi ``` I feel like for non-compiler cross-XXX packages it should read: ``` # cross-aarch64-gentoo-linux-musl -> aarch64-gentoo-linux-musl if [[ ${_IS_CROSSPKG} == 1 ]]; then export CHOST=${CATEGORY#${_CROSS_CATEGORY_PREFIX}} # Ugh, we kind of need to set all the variables... if [[ ${_IS_CROSSPKG_LLVM} == 1 ]]; then export CC="${CHOST}-llvm" export LD="${CHOST}-ld.lld" else export CC="${CHOST}-gcc" export LD="${CHOST}-ld" fi fi ``` > Can't remember exactly where in the LLVM bootstrap process I needed libxcrypt (definitely needed the headers very early, unsure about the actual lib). We use the cross-XXX/libxcrypt package in two packages: * cross-XXX/compiler-rt: https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/e83e89404be4eda47297944c43ed0961c39b6055/sys-libs/compiler-rt/compiler-rt-9999.ebuild#54 * dev-lang/rust: https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/e83e89404be4eda47297944c43ed0961c39b6055/dev-lang/rust/rust-9999.ebuild#70
Thanks Raul, I confirmed the compiler-rt sanitizers require libxcrypt when bootstrapping, so my headers-only theory does not work. I have no opinion on the CHOST vs CTARGET issue... @Mike @James or @Sam do you have any ideas on Raul's suggestion?
I think we could apply the hack from the PR as a short term solution. Longer term, I think the fix belongs in crossdev: we should override CHOST and CC via /etc/portage/env/${CROSSDEV_OVERLAY_CATEGORY}/libxcrypt.conf. That takes all the guesswork out of it.
> we should override CHOST and CC via /etc/portage/env/${CROSSDEV_OVERLAY_CATEGORY}/libxcrypt.conf. That takes all the guesswork out of it. That sounds like a great idea!
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=512953539d79ad8c4b0b97375b6d29f5932c1d46 commit 512953539d79ad8c4b0b97375b6d29f5932c1d46 Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2025-02-20 03:57:09 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2025-02-21 16:36:37 +0000 sys-libs/libxcrypt: restore hack to reset CC based on CTARGET Closes: https://bugs.gentoo.org/949976 Signed-off-by: Mike Gilbert <floppym@gentoo.org> sys-libs/libxcrypt/libxcrypt-4.4.36-r3.ebuild | 16 +++++++++------- sys-libs/libxcrypt/libxcrypt-4.4.38.ebuild | 14 ++++++++------ 2 files changed, 17 insertions(+), 13 deletions(-)
Filed bug 950032 for the possible crossdev change.
