dev-libs/libsecp256k1 fails to build on the llvm profile (without GCC installed) because its configure.ac uses the AX_PROG_CXX_FOR_BUILD macro from dev-build/autoconf-archive to select a toolchain to use for building code to run on the build system. Setting CC, CXX, et al. to Clang/LLVM values does not influence the selection logic in AX_PROG_CC_FOR_BUILD or AX_PROG_CXX_FOR_BUILD, as those macros are looking in the environment for variables having names suffixed with "_FOR_BUILD" and default to ${CBUILD}-prefixed GCC values when those variables are not found. It seems sensible that profiles/features/llvm/make.defaults should be setting: CC_FOR_BUILD="${CC}" CXX_FOR_BUILD="${CXX}" CPP_FOR_BUILD="${CPP}" CXXCPP_FOR_BUILD="${CXXCPP}" CFLAGS_FOR_BUILD="${CFLAGS}" CXXFLAGS_FOR_BUILD="${CXXFLAGS}" CPPFLAGS_FOR_BUILD="${CPPFLAGS}" CXXCPPFLAGS_FOR_BUILD="${CXXCPPFLAGS}" This will ensure that AX_PROG_CC_FOR_BUILD and AX_PROG_CXX_FOR_BUILD do not default to GCC for the build-system toolchain but rather utilize the Clang/LLVM counterparts as intended by the profile. Note: I've never personally seen ${CXXCPP} or ${CXXCPPFLAGS} used in the wild, but Autoconf apparently does respect them.
Isn't this a case for tc-export_build_env?
(In reply to Michał Górny from comment #1) > Isn't this a case for tc-export_build_env? Either I was not aware of that or had forgotten it. Thanks for the pointer. Is there a good rationale for *not* exporting variables for the build-machine toolchain by default? It is not always obvious to package maintainers when a package's build system compiles code to run on the build machine during the build, especially when maintainers typically don't develop ebuilds in a cross-compiling environment, so it can be difficult to know when calling tc-export_build_env is necessary, to the point that I might just start calling it in every ebuild I write to be on the safe side. It wouldn't hurt to export the build-machine toolchain environment by default (in the next EAPI), would it? Incidentally, tc-export_build_env is awkward to use when the package's build system is expecting variable names suffixed with "_FOR_BUILD", such as is the case with AX_PROG_CC_FOR_BUILD from Autoconf Archive, as I am then needing to do this little dance: tc-export_build_env BUILD_CC BUILD_CPP export CC_FOR_BUILD="${BUILD_CC}" CPP_FOR_BUILD="${BUILD_CPP}"
