| Summary: | dev-libs/libsecp256k1-0.4.1 fails to compile (MUSL-CLANG-SYSTEM): x86_64-gentoo-linux-musl-gcc: error: unrecognized command-line option -Wconditional-uninitialized | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Agostino Sarubbo <ago> |
| Component: | Current packages | Assignee: | Luke-Jr <luke-jr+gentoobugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | concord, gentoo, proxy-maint |
| Priority: | Normal | Keywords: | PullRequest |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: |
https://github.com/gentoo/gentoo/pull/35652 https://github.com/gentoo/gentoo/pull/35657 |
||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | build.log | ||
|
Description
Agostino Sarubbo
2023-02-17 08:16:29 UTC
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(-) |