Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 895048 - 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
Summary: dev-libs/libsecp256k1-0.4.1 fails to compile (MUSL-CLANG-SYSTEM): x86_64-gent...
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Luke-Jr
Keywords: PullRequest
Depends on:
Reported: 2023-02-17 08:16 UTC by Agostino Sarubbo
Modified: 2024-03-21 02:41 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---

build.log (build.log,54.92 KB, text/plain)
2023-02-17 08:16 UTC, Agostino Sarubbo

Note You need to log in before you can comment on or make changes to this bug.
Description Agostino Sarubbo gentoo-dev 2023-02-17 08:16:29 UTC

Issue: dev-libs/libsecp256k1-0.2.0-r2 fails to compile (MUSL-CLANG-SYSTEM).
Discovered on: amd64 (internal ref: tinderbox_musl)

(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.
Comment 1 Agostino Sarubbo gentoo-dev 2023-02-17 08:16:31 UTC
Created attachment 851962 [details]

build log and emerge --info
Comment 2 Kenton Groombridge gentoo-dev 2023-05-26 15:16:52 UTC
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}"

Comment 3 Agostino Sarubbo gentoo-dev 2024-02-06 16:23:28 UTC
clang-lld_tinderbox has reproduced this issue with version 0.4.1 - Updating summary.
Comment 4 Matt Whitlock 2024-03-07 19:54:20 UTC
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.
Comment 5 Matt Whitlock 2024-03-07 21:27:16 UTC
(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.
Comment 6 Larry the Git Cow gentoo-dev 2024-03-21 02:41:19 UTC
The bug has been closed via the following commit(s):

commit 26a25bce171b96ebdbe4e16f6398ad7769613eef
Author:     Matt Whitlock <>
AuthorDate: 2024-03-07 21:10:22 +0000
Commit:     Sam James <>
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
    building the build-time executables.
    [sam: Add Closes tag for #35652 too.]
    Signed-off-by: Matt Whitlock <>
    Signed-off-by: Sam James <>

 ...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(-)