https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: dev-libs/libsecp256k1-0.2.0-r2 fails to compile (MUSL-CLANG-SYSTEM). Discovered on: amd64 (internal ref: tinderbox_musl) NOTE: (MUSL-CLANG-SYSTEM) in the summary means that bug was found on a machine that runs MUSL libc + clang16 but this bug MAY or MAY NOT BE related to musl/clang16.
Created attachment 851962 [details] build.log build log and emerge --info
I spent about 10 minutes on this and found that the included patch with the ebuild seems to introduce a bug to the build system where it properly selects clang as the host compiler to use, but fails to actually use it during the build (defaulting to GCC). As a workaround I added this snippet to the ebuild which at least got it building with clang, though I'm unsure if this breaks any of the cross-compiling logic: --- src_install() { emake CC_FOR_BUILD="${CC}" } ---
clang-lld_tinderbox has reproduced this issue with version 0.4.1 - Updating summary.
I suspect that the workaround at the linked PR may be incomplete. Suppose that the user is cross-compiling using clang on a gcc-native build machine — that is, "${CHOST}-clang" and "${CBUILD}-gcc" exist, but "${CHOST}-gcc" and "${CBUILD}-clang" do not exist. The feature detection performed by Autoconf will configure CFLAGS for the CC="${CHOST}-clang" compiler, but then the CC_FOR_BUILD="${CBUILD}-gcc" compiler will be called to compile the build-time executables. What CFLAGS will be passed to ${CC_FOR_BUILD}? The ones that Autoconf configured for "${CHOST}-clang"? That will cause exactly the same failure as reported here: "unrecognized command-line option -Wconditional-uninitialized". So it seems to me that a more complete fix would be for the build system not to assume that the results of its flag feature tests are applicable to the compiler chosen to compile the build-time executables. Then, on the MUSL-CLANG-SYSTEM originating this bug report, x86_64-gentoo-linux-musl-gcc will still be called to compile the build-time executables, but it will not be passed the flags that only apply to clang. As a side note, if MUSL-CLANG-SYSTEM really wants ebuilds to use only clang and never gcc, then it should be explicitly setting CC_FOR_BUILD="clang" in the environment like it explicitly sets CC="clang". Absent that, the current setup is effectively saying, "Please use 'clang' to compile executables for the host system (CHOST), and I have no preference regarding the compiler you use to compile executables for the build system (CBUILD)." Such a setup *rightly* allows Autoconf to select x86_64-gentoo-linux-musl-gcc as CC_FOR_BUILD. Second side note: Arguably, AX_PROG_CC_FOR_BUILD should first attempt to use ${CC} as the CC_FOR_BUILD in the case that ${CBUILD} == ${CHOST}, rather than first attempting "${build}-gcc", but that is a logically separate issue.
(In reply to Matt Whitlock from comment #4) > So it seems to me that a more complete fix would be for the build system not > to assume that the results of its flag feature tests are applicable to the > compiler chosen to compile the build-time executables. The patch I crafted had been attempting to do exactly this, but I failed to realize that Automake does things a little differently than a vanilla Makefile would. I have opened a PR to fix the patch so that it _actually_ uses CFLAGS_FOR_BUILD, CPPFLAGS_FOR_BUILD, and LDFLAGS_FOR_BUILD when building the build-time executables. This solves the build failure for me when overriding CC="clang" by environment variable.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=26a25bce171b96ebdbe4e16f6398ad7769613eef commit 26a25bce171b96ebdbe4e16f6398ad7769613eef Author: Matt Whitlock <gentoo@mattwhitlock.name> AuthorDate: 2024-03-07 21:10:22 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-03-21 02:36:00 +0000 dev-libs/libsecp256k1: fix build when CC is overridden to clang The libsecp256k1 build system detects compiler flag feature support using ${CC} but then builds the build-time executables using ${CC_FOR_BUILD}. When CC and CC_FOR_BUILD refer to different brands or versions of compilers, the feature detection for one will not be applicable to the other. Previous to this commit, our cross-compilation support patch attempted to override the flags when building the build-time executables, but it was doing so in a way that Automake does not respect. This commit fixes the patch so that Automake will actually use CFLAGS_FOR_BUILD, CPPFLAGS_FOR_BUILD, and LDFLAGS_FOR_BUILD when building the build-time executables. [sam: Add Closes tag for #35652 too.] Closes: https://bugs.gentoo.org/895048 Signed-off-by: Matt Whitlock <gentoo@mattwhitlock.name> Closes: https://github.com/gentoo/gentoo/pull/35652 Closes: https://github.com/gentoo/gentoo/pull/35657 Signed-off-by: Sam James <sam@gentoo.org> ...compile.patch => 0.3.0-fix-cross-compile.patch} | 50 ++++++----- .../files/0.4.0-fix-cross-compile.patch | 99 ++++++++++++++++++++++ dev-libs/libsecp256k1/libsecp256k1-0.3.0.ebuild | 2 +- dev-libs/libsecp256k1/libsecp256k1-0.3.1.ebuild | 2 +- dev-libs/libsecp256k1/libsecp256k1-0.3.2.ebuild | 2 +- dev-libs/libsecp256k1/libsecp256k1-0.4.0.ebuild | 2 +- dev-libs/libsecp256k1/libsecp256k1-0.4.1.ebuild | 2 +- 7 files changed, 135 insertions(+), 24 deletions(-)
