From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id BE59A158041 for ; Thu, 28 Mar 2024 04:58:20 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 234D5E2A1F; Thu, 28 Mar 2024 04:58:15 +0000 (UTC) Received: from mail-yw1-x1134.google.com (mail-yw1-x1134.google.com [IPv6:2607:f8b0:4864:20::1134]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id CE15CE2A18 for ; Thu, 28 Mar 2024 04:58:14 +0000 (UTC) Received: by mail-yw1-x1134.google.com with SMTP id 00721157ae682-609fb0450d8so6111297b3.0 for ; Wed, 27 Mar 2024 21:58:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711601893; x=1712206693; darn=lists.gentoo.org; h=content-transfer-encoding:mime-version:message-id:date:subject:to :from:from:to:cc:subject:date:message-id:reply-to; bh=6d9eu93yfTJBSZzsrCgneXmtGdij9RMe4izDZWP1T2w=; b=iKacJgNEsYDXiLLTjSqzlI0BCPfyMLtAKWCx+eVds+Tu39Ke7WETonJwAimB8JlOXd /pwakwi4uSwHp9s10j0aefoPfieO37Wyvd2zppM+pID+yak2pRo1hCoutYsYbReYjmHc uTiCwLlyRIbOwywg47o3KbRzsLupPEsuWDKkgciBijOAogOlEX/la3tpS9I1dMjGxgTl mEl965Jpq50jHX9Vpay/0KVGJmvij5fWG229JgiZg2r5eznfNsOgLMX/vNwquBYdvbtA jM3QlTQJLTIBhauSXvTeU141utfqadrCz4NNfnLRXkOtcdfqfHfshEHzJ3BsXUHsFE+Z SJTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711601893; x=1712206693; h=content-transfer-encoding:mime-version:message-id:date:subject:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=6d9eu93yfTJBSZzsrCgneXmtGdij9RMe4izDZWP1T2w=; b=NpxPGY2BQUUBz1I+M3cjqAUmh6o+vh7FNArhHd4r3IZpdYnmq5KMGAA/HSDm8R/Bm+ fIboVh9bZI2h2Hh5dRHGW5nM6M2fKiUQEiMHUL9V+Mc6oMazpmkmc8Je8FO+VhsukzKx hlrWkuURf66uTxpfnlt8B/pQrhAOYp+/q9v9xWESNIJPxM5R87b7ppIVdIwY0/MQupux AGBrHOQUUE1I9CpqFJRZ5aju8gveNpOQY+A/5r15vpKunUcoZLfmyg94UFqCpu+cF2Ep 5AFJOuZvFkh9PjcDolu75QE7ETQ+vOhFn7LlDmFDJD0+UpTY604dhJC02CrAXRhH2WJ6 3dDA== X-Gm-Message-State: AOJu0YwWGKiM5HGSR4v6yG1GhjrCnDBrR5DGRzgKbcBJPW82Du6JI3gG 8un4pD2bFAc+0cgRHurOuj6B9NJFHvk9t10aPHW5+ooR5UL8zZTn5F9oyQ0G X-Google-Smtp-Source: AGHT+IG8tcHcnTE2qy7bjsqqSdxDrqRLWXW4E2xxvMkBgD8WBB0BJB4jC4Bn1UkcU7gYbZh33HZvtA== X-Received: by 2002:a81:5d02:0:b0:610:e9b2:f84a with SMTP id r2-20020a815d02000000b00610e9b2f84amr1857093ywb.26.1711601893014; Wed, 27 Mar 2024 21:58:13 -0700 (PDT) Received: from acleverhostname.attlocal.net (108-200-163-197.lightspeed.bcvloh.sbcglobal.net. [108.200.163.197]) by smtp.gmail.com with ESMTPSA id q8-20020a81c648000000b00609f060cecbsm128039ywj.129.2024.03.27.21.58.12 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Mar 2024 21:58:12 -0700 (PDT) From: Eli Schwartz To: gentoo-dev@lists.gentoo.org Subject: [gentoo-dev] [PATCH] flag-o-matic.eclass: simplify implementation and work in all cases Date: Thu, 28 Mar 2024 00:58:11 -0400 Message-ID: <20240328045811.2289466-1-eschwartz93@gmail.com> X-Mailer: git-send-email 2.43.2 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Archives-Salt: 12a6077a-5a6a-48a9-bf87-e8092020cc4d X-Archives-Hash: 7c903a127041d898aecf9c54e1ef6846 It curently uses some magic test to decide whether handcrafted code works with or without -latomic. But it can claim that -latomic is not needed for that case, while it is still needed for other cases. > okay so append-atomic-flags does not work for me in this case > noise-suppression-for-voice is doing `struct RnNoiseStats { uint32_t a, b, c, d; }; std::atomic m_stats;` > not just a single large integer It is simplest to always add -latomic when an ebuild gets that deep feeling that yeah, it would like some atomics please. The downsides to listing a linker library are exactly: - it might be unavailable - it might be unneeded And the former case is trivial to solve -- this function already does so -- while the latter case has a sanctioned approach that is already used for other intrinsic compiler libraries, but not for atomic "because the build system would have a hard time if we had to build atomic early on" which isn't a very good reason to break ebuilds which aren't building sys-devel/gcc. As a side benefit, we now handle -latomic such that a package which requires it, but only for parts of the installed package, does not overlink to libatomic in *all* binaries/libraries, even if the default LDFLAGS are overridden and the global -Wl,--as-needed disappears. Bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358 Bug: https://bugs.gentoo.org/820101 Bug: https://bugs.gentoo.org/925672 Signed-off-by: Eli Schwartz --- eclass/flag-o-matic.eclass | 80 +++++++++----------------------------- 1 file changed, 19 insertions(+), 61 deletions(-) diff --git a/eclass/flag-o-matic.eclass b/eclass/flag-o-matic.eclass index 5ce7601fdde2..0e5271c7824f 100644 --- a/eclass/flag-o-matic.eclass +++ b/eclass/flag-o-matic.eclass @@ -1015,69 +1015,27 @@ test-compile() { } # @FUNCTION: append-atomic-flags -# @USAGE: [bytes] # @DESCRIPTION: -# Attempts to detect if appending -latomic is required to use -# a specific-sized atomic intrinsic, and if so, appends it. If the bytesize -# is not specified, then check the four most common byte sizes (1, 2, 4, 8). -# >=16-byte atomics are not included in this default set and must be explicitly -# passed if required. This may require you to add a macro definition like -# -Duint128_t=__uint128_t to your CFLAGS. +# Attempts to detect if appending -latomic works, and does so. append-atomic-flags() { - # this implementation is as described in bug #820101 - local code - - # first, ensure we can compile a trivial program - # this is because we can't distinguish if test-compile - # fails because -latomic is actually needed or if we have a - # broken toolchain (like due to bad FLAGS) - read -r -d '' code <<- EOF - int main(void) - { - return 0; - } - EOF - - # if toolchain is broken, just return silently. it's better to - # let other pieces of the build fail later down the line than to - # make people think that something to do with atomic support is the - # cause of their problems. - test-compile "c+ld" "${code}" || return - - local bytesizes - [[ "${#}" == "0" ]] && bytesizes=( "1" "2" "4" "8" ) || bytesizes="${@}" - - for bytesize in ${bytesizes[@]} - do - # this sample program is informed by the great testing from the buildroot project: - # https://github.com/buildroot/buildroot/commit/6856e417da4f3aa77e2a814db2a89429af072f7d - read -r -d '' code <<- EOF - #include - int main(void) - { - uint$((${bytesize} * 8))_t a = 0; - __atomic_add_fetch(&a, 3, __ATOMIC_RELAXED); - __atomic_compare_exchange_n(&a, &a, 2, 1, __ATOMIC_RELAXED, __ATOMIC_RELAXED); - return 0; - } - EOF - - # do nothing if test program links fine - test-compile "c+ld" "${code}" && continue - - # ensure that the toolchain supports -latomic - test-flags-CCLD "-latomic" &>/dev/null || die "-latomic is required but not supported by $(tc-getCC)" - - append-libs "-latomic" - - # verify that this did indeed fix the problem - test-compile "c+ld" "${code}" || \ - die "libatomic does not include an implementation of ${bytesize}-byte atomics for this toolchain" - - # if any of the required bytesizes require -latomic, no need to continue - # checking the others - return - done + # Make sure that the flag is actually valid. If it isn't, then maybe the + # library both doesn't exist and is redundant, or maybe the toolchain is + # broken, but let the build succeed or fail on its own. + test-flags-CCLD "-latomic" &>/dev/null || return + + # We unconditionally append this flag. In the case that it's needed, the + # flag is, well, needed. In the case that it's not needed, it causes no + # harm, because we ensure that this specific library is definitely + # certainly linked with as-needed. + # + # Really, this should be implemented directly in the compiler, including + # the use of push/pop for as-needed. It's exactly what the gcc spec file + # does for e.g. -lgcc_s, but gcc is concerned about doing so due to build + # system internals and as a result all users have to deal with this mess + # instead. + # + # See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358 + append-libs "-Wl,--push-state,--as-needed,-latomic,--pop-state" } fi -- 2.43.2