fanquake
commented at 9:57 AM on June 16, 2023:
member
Switch to using GCC 12.3.0 to build release binaries.
Temporarily disables the powerpc64le-linux-gnu target due to non-determinism issues when building across aarch64 and x86_64. Trying to fix the non-determinism was going to require trying to selectively disable optimization flags, which is already not ideal (and didn't fix all issues), and the migration to GCC 12 as our release compiler is now the blocker for multiple other (c++20 and similar) changes, so leaving this blocked on the powerpc64le binaries does not seem like a good tradeoff.
DrahtBot
commented at 9:57 AM on June 16, 2023:
contributor
<!--e57a25ab6845829454e8d69fc972939a-->
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.
<!--174a7506f384e20aa4161008e828411d-->
Conflicts
Reviewers, this pull request conflicts with the following ones:
#25972 (build: no-longer disable WARN_CXXFLAGS when CXXFLAGS is set by fanquake)
#25573 ([POC] guix: produce a fully -static-pie bitcoind by fanquake)
#25391 (guix: Use LTO to build releases by fanquake)
#24123 (build: Pointer Authentication and Branch Target Identification for aarch64 Linux (Guix) by fanquake)
#21778 (build: LLD based macOS toolchain by fanquake)
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.
DrahtBot added the label Build system on Jun 16, 2023
maflcko added the label DrahtBot Guix build requested on Jun 21, 2023
fanquake force-pushed on Jun 21, 2023
theuni
commented at 5:24 PM on June 21, 2023:
member
Concept ACK.
I'm having trouble finding where ppc64 became unsupported in guix though. There were lots of refactors and I'm guessing some wildcard change is maybe responsible? I'd like to understand why it was disabled just in case it was accidental. In that case, we'd want to upstream a fix I think?
DrahtBot removed the label DrahtBot Guix build requested on Jun 21, 2023
fanquake referenced this in commit 0c84a0e484 on Jun 22, 2023
fanquake force-pushed on Jun 22, 2023
maflcko
commented at 9:01 AM on June 23, 2023:
member
I think you forgot to bump the CI?
diff --git a/ci/test/00_setup_env_win64.sh b/ci/test/00_setup_env_win64.sh
index 3adfbf6e4..e0671e734 100755
--- a/ci/test/00_setup_env_win64.sh
+++ b/ci/test/00_setup_env_win64.sh
@@ -7,7 +7,7 @@
export LC_ALL=C.UTF-8
export CONTAINER_NAME=ci_win64
-export CI_IMAGE_NAME_TAG=ubuntu:22.04 # Check that Jammy can cross-compile to win64
+export CI_IMAGE_NAME_TAG=debian:bookworm # Check that Bookworm (gcc 12, similar to guix) can cross-compile
export HOST=x86_64-w64-mingw32
export DPKG_ADD_ARCH="i386"
export PACKAGES="python3 nsis g++-mingw-w64-x86-64-posix wine-binfmt wine64 wine32 file"
and the same for arm? Similar to commit 0999999d1d2112e9fba473f6057c8096b4775852
in
contrib/guix/manifest.scm:83
in
648d9e7761outdated
Why are these no longer needed? Smarter gcc or guix changes?
theuni
commented at 2:15 PM on June 23, 2023:
member
Looking good to me.
Mind adding a more verbose commit message for "guix: remove input labels"? I could use some help with the motivation for that one.
DrahtBot added the label Needs rebase on Jun 27, 2023
maflcko added the label DrahtBot Guix build requested on Jun 27, 2023
hebasto
commented at 9:41 AM on June 27, 2023:
member
Switch to using GCC 12 to build release binaries.
Concept ACK on this.
hebasto
commented at 12:19 PM on June 30, 2023:
member
macOS builds are failing because libtapi fails to configure against the newer GCC.
FWIW, libtapi configuration step succeeds for the Guix master branch (94ac93042f09b4ba68b7b64ed1feeebd3dab1ea4). However, the further build step fails.
fanquake force-pushed on Jun 30, 2023
DrahtBot removed the label Needs rebase on Jun 30, 2023
DrahtBot removed the label DrahtBot Guix build requested on Jul 1, 2023
fanquake
commented at 2:21 PM on July 3, 2023:
member
Re-enable / follow up with powerpc64-linux-gnu builds.
Other stuff.
maflcko added the label DrahtBot Guix build requested on Jul 27, 2023
DrahtBot removed the label DrahtBot Guix build requested on Jul 27, 2023
fanquake force-pushed on Aug 2, 2023
fanquake force-pushed on Aug 2, 2023
fanquake
commented at 12:26 PM on August 2, 2023:
member
Rebased on master.
Updated the time-machine to current Guix master.
Fixed macOS builds by retaining GCC 10 in it's manifest. This seems like the most straight-forward way to proceed here, given this code is going to be removed soon in any case (and GCC isn't used for the bitcoind builds).
There is currently a non-determinism issue (x86_64 vs aarch64) with the powerpc64le-linux-gnu build.
DrahtBot added the label DrahtBot Guix build requested on Aug 2, 2023
DrahtBot removed the label DrahtBot Guix build requested on Aug 3, 2023
fanquake
commented at 3:04 PM on August 8, 2023:
member
Upstreamed a patch to (re-)add powerpc64-linux as a platform definition in Guix: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=65151. Using a self-compiled Guix with this patch, fixes building our cross-compilation toolchain for powerpc64-linux-gnu, and means we'd just drop 26ee1fc5998cce6808f022fd1a4e1764115c2d57 from this PR.
fanquake
commented at 11:49 AM on August 14, 2023:
member
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=65151 landed in Guix. So I've updated the time-machine to include that change, and removed the commit dropping supported for powerpc64-linux-gnu. The last TODO here is resolve the determinism issue with the powerpc64le-linux-gnu build.
maflcko added the label DrahtBot Guix build requested on Aug 14, 2023
DrahtBot removed the label DrahtBot Guix build requested on Aug 15, 2023
fanquake force-pushed on Aug 17, 2023
DrahtBot added the label CI failed on Aug 18, 2023
fanquake referenced this in commit 00fe455019 on Aug 18, 2023
fanquake referenced this in commit 51324c9517 on Aug 18, 2023
fanquake referenced this in commit 4c3ebc7669 on Aug 18, 2023
fanquake referenced this in commit e1a075eafe on Aug 22, 2023
fanquake referenced this in commit 8372ab0ea3 on Aug 22, 2023
DrahtBot added the label Needs rebase on Aug 22, 2023
fanquake force-pushed on Aug 23, 2023
DrahtBot removed the label CI failed on Aug 23, 2023
DrahtBot removed the label Needs rebase on Aug 23, 2023
fanquake force-pushed on Aug 23, 2023
fanquake
commented at 1:13 PM on August 23, 2023:
member
This is now based on #28324 and #28328. Please review those first.
fanquake force-pushed on Aug 23, 2023
fanquake referenced this in commit f3cc29fc5f on Aug 24, 2023
DrahtBot added the label Needs rebase on Aug 24, 2023
fanquake force-pushed on Aug 24, 2023
DrahtBot removed the label Needs rebase on Aug 24, 2023
fanquake referenced this in commit 03675b2ba3 on Aug 26, 2023
fanquake force-pushed on Aug 26, 2023
fanquake force-pushed on Aug 27, 2023
fanquake marked this as ready for review on Aug 27, 2023
fanquake
commented at 2:04 PM on August 27, 2023:
member
Moved this out of draft now that there are no-longer any dependencies. Should still have 1 determinism issue to fixup, and not completely happy with the gcc-toolchain split, so might see if we can work around it another way. Otherwise, ready for review/feedback. Not sure if I want to include CI/docs changes here.
maflcko
commented at 2:18 PM on August 27, 2023:
member
Not sure if I want to include CI/docs changes here.
Any reason not to, given that they should be trivial and all you need to do is to cherry-pick them?
maflcko
commented at 10:33 AM on August 28, 2023:
member
So yeah, powerpc64le has a mismatch.
fanquake
commented at 10:35 AM on August 28, 2023:
member
Any reason not to, given that they should be trivial and all you need to do is to cherry-pick them?
Can you point to the complete set of commits I need to cherry pick. I didn't want to include non guix/builds changes here because that just makes getting review for the entire set of changes harder. Basically the inverse reasoning of #28210 (comment).
maflcko
commented at 10:46 AM on August 28, 2023:
member
I think we should keep the cross tasks (windows, macos, and one linux) in sync with the guix config, to catch guix gcc compile errors in CI before merge or before doing a guix build.
For macos-cross, no changes are needed, because it doesn't use the system compiler. However, for the other tasks, the system should be picked, so that it matches the guix compiler, no?
Thus, my recommended changes are:
diff --git a/ci/test/00_setup_env_arm.sh b/ci/test/00_setup_env_arm.sh
index 65d37f01d9..c80036164f 100755
--- a/ci/test/00_setup_env_arm.sh
+++ b/ci/test/00_setup_env_arm.sh
@@ -1,6 +1,6 @@
#!/usr/bin/env bash
#
-# Copyright (c) 2019-2021 The Bitcoin Core developers
+# Copyright (c) 2019-present The Bitcoin Core developers
# Distributed under the MIT software license, see the accompanying
# file COPYING or http://www.opensource.org/licenses/mit-license.php.
@@ -10,7 +10,7 @@ export HOST=arm-linux-gnueabihf
export DPKG_ADD_ARCH="armhf"
export PACKAGES="python3-zmq g++-arm-linux-gnueabihf busybox libc6:armhf libstdc++6:armhf libfontconfig1:armhf libxcb1:armhf"
export CONTAINER_NAME=ci_arm_linux
-export CI_IMAGE_NAME_TAG="docker.io/arm64v8/debian:bookworm"
+export CI_IMAGE_NAME_TAG="docker.io/arm64v8/debian:bookworm" # Check that https://packages.debian.org/bookworm/g++-arm-linux-gnueabihf (version 12.2, similar to guix) can cross-compile
export USE_BUSY_BOX=true
export RUN_UNIT_TESTS=true
export RUN_FUNCTIONAL_TESTS=false
diff --git a/ci/test/00_setup_env_win64.sh b/ci/test/00_setup_env_win64.sh
index ebd4487c52..4cd845c065 100755
--- a/ci/test/00_setup_env_win64.sh
+++ b/ci/test/00_setup_env_win64.sh
@@ -7,7 +7,7 @@
export LC_ALL=C.UTF-8
export CONTAINER_NAME=ci_win64
-export CI_IMAGE_NAME_TAG="docker.io/amd64/ubuntu:22.04" # Check that Jammy can cross-compile to win64
+export CI_IMAGE_NAME_TAG="docker.io/amd64/debian:bookworm" # Check that https://packages.debian.org/bookworm/g++-mingw-w64-x86-64-posix (version 12.2, similar to guix) can cross-compile
export HOST=x86_64-w64-mingw32
export DPKG_ADD_ARCH="i386"
export PACKAGES="nsis g++-mingw-w64-x86-64-posix wine-binfmt wine64 wine32 file"
fanquake
commented at 11:20 AM on August 28, 2023:
member
The difference I'm seeing in the aarch64 vs x86_64 builds is re-ordering of lines in debug output (which then shows up in the bins via the .dbg checksum). i.e:
fanquake
commented at 8:44 AM on August 29, 2023:
member
Thus, my recommended changes are:
Implented & rebased.
fanquake
commented at 10:34 AM on August 29, 2023:
member
This can be isolated to void std::vector<uint256, std::allocator<uint256> >::_M_realloc_insert<>(__gnu_cxx::__normal_iterator<uint256*, std::vector<uint256, std::allocator<uint256> > >) in src/wallet/libbitcoin_wallet_a-walletdb.cpp.
If you dump out the contents of _ZNSt6vectorI7uint256SaIS0_EE17_M_realloc_insertIJEEEvN9__gnu_cxx17__normal_iteratorIPS0_S2_EEDpOT_ from that object file i.e
I believethis is the function in question. Though it's not clear to me if the function has anything to do with the determinism problem, or if the compiler just happens to run into some pattern here.
fanquake
commented at 1:09 PM on August 29, 2023:
member
fanquake
commented at 11:21 AM on August 30, 2023:
member
I assume the Win64 native CI failure is sporadic, but I guess the win64 cross-compile failure will need actual changes:
test/system_tests.cpp(59): error: in "system_tests/run_command": check e.code().value() == expected_error has failed [2 != 6]
test/system_tests.cpp(26): Leaving test case "run_command"; testing time: 495559us
test/system_tests.cpp(15): Leaving test suite "system_tests"; testing time: 537416us
Not sure why we've got unit tests that seem to be dependant on the host OS/library versions (seems to be Wine here) on the system? cc @hebasto.
maflcko
commented at 11:44 AM on August 30, 2023:
member
The CI task name says no boost::process, so I think the fix would be to remove boost::process from that task or fix the task name along with the test issue (in a separate pull), no?
maflcko
commented at 11:52 AM on August 30, 2023:
member
Can you try with:
diff --git a/src/test/system_tests.cpp b/src/test/system_tests.cpp
index 740f461548..260f7f6645 100644
--- a/src/test/system_tests.cpp
+++ b/src/test/system_tests.cpp
@@ -49,11 +49,7 @@ BOOST_AUTO_TEST_CASE(run_command)
}
{
// An invalid command is handled by Boost
-#ifdef WIN32
- const int expected_error{wine_runtime ? 6 : 2};
-#else
const int expected_error{2};
-#endif
BOOST_CHECK_EXCEPTION(RunCommandParseJSON("invalid_command"), boost::process::process_error, [&](const boost::process::process_error& e) {
BOOST_CHECK(std::string(e.what()).find("RunCommandParseJSON error:") == std::string::npos);
BOOST_CHECK_EQUAL(e.code().value(), expected_error);
fanquake force-pushed on Aug 30, 2023
fanquake
commented at 12:32 PM on August 30, 2023:
member
The CI task name says no boost::process,
Yea I guess that is wrong, as the config explicitly enables --enable-external-signer. Pushed up your suggested diff as part of the Win CI commit for now (can be split out too).
DrahtBot removed the label CI failed on Aug 30, 2023
fanquake referenced this in commit 505ea30b47 on Aug 30, 2023
fanquake force-pushed on Aug 30, 2023
hebasto
commented at 2:51 PM on September 1, 2023:
member
FWIW, using the -O1 optimization level fixes cross-platform reproducibility.
Perhaps, it is feasible to use an approach similar to #25643?
theuni
commented at 3:23 PM on September 1, 2023:
member
FWIW, using the -O1 optimization level fixes cross-platform reproducibility.
Perhaps, it is feasible to use an approach similar to #25643?
Agree that would work, but hopefully as a last resort.
The ideal fix would be to track down the actual gcc issue. A possible route to doing so:
Since we know the non-determinism is introduced by one or more optimizations, one-by-one, append the individual -O2 sub-options on top of -O1 until the culprit is found.
For ex, the gcc docs say that -O2 is the same as -O1 plus:
So.. start with -O1 -falign-functions, -O1 -falign-jumps, -O1 -fcaller-saves etc. until the non-determinism is introduced. Hopefully it's a single flag.
From there, presumably we'd know which class or pass of optimization is the problem. We could use that to narrow down a bisection, since I believe we also know which version of gcc introduced the problem.
maflcko
commented at 3:33 PM on September 1, 2023:
member
What is the easiest way in guix to bisect gcc? Can I modify the gcc package description locally without having guix check any signatures on it when putting it in the time machine?
fanquake force-pushed on Sep 6, 2023
fanquake marked this as a draft on Sep 6, 2023
fanquake
commented at 3:46 PM on September 6, 2023:
member
What is the easiest way in guix to bisect gcc?
I will post a guide for doing this.
In the mean time, turning this back into a draft as it's now based off #28422, which if done, means we don't have to split our native toolchains between GCC 12 and GCC 10, which is much cleaner.
fanquake referenced this in commit b097a689ed on Sep 7, 2023
fanquake force-pushed on Sep 7, 2023
fanquake marked this as ready for review on Sep 7, 2023
fanquake
commented at 2:32 PM on September 7, 2023:
member
Rebased, undrafted, updated PR description. The changes here are now smaller.
Frank-GER referenced this in commit d367953adb on Sep 8, 2023
Frank-GER referenced this in commit 74569677f6 on Sep 8, 2023
Frank-GER referenced this in commit b3b8f40a4f on Sep 8, 2023
Frank-GER referenced this in commit a5c099f5a4 on Sep 8, 2023
fanquake
commented at 1:03 PM on September 11, 2023:
member
From what I can see, the pair of optimisation flags causing the issue is -fgcse & -fschedule-insns. When both are passed we get non-determinism, independently (at -O1) they are deterministic.
in
src/test/system_tests.cpp:60
in
ae2cd3fe25outdated
48 | @@ -49,11 +49,7 @@ BOOST_AUTO_TEST_CASE(run_command)
49 | }
50 | {
51 | // An invalid command is handled by Boost
52 | -#ifdef WIN32 53 | - const int expected_error{wine_runtime ? 6 : 2}; 54 | -#else
55 | const int expected_error{2};
56 | -#endif
hebasto
commented at 12:52 PM on September 13, 2023:
9a04ca1cd0921c80f4836a07f2a2198fbd43cf05
The error reporting has been changed in Wine 8.0 (Debian Bookworm, Ubuntu Lunar):
in Wine 6.x and 7.x, it was:
message: "CreateProcess failed: No such device or address"
code: 6
in Wine 8.0:
message: "CreateProcess failed: File not found"
code: 2
I'm not sure about the exact commit, though.
I agree with these changes and don't want to introduce more testing code to handle different Wine versions.
However, I'm suggesting to document that Wine 8+ is required to run Windows unit tests.
fanquake
commented at 12:55 PM on September 13, 2023:
Do you want to split commit this into a separate PR, and add the documentation?
maflcko
commented at 12:58 PM on September 13, 2023:
I think documentation was missing previously either way on the required wine version, so this seems unrelated?
fanquake
commented at 1:01 PM on September 13, 2023:
I guess this will also means anyone that wants to run the windows unit tests will need to be running Lunar or later, or install Wine themselves.
hebasto
commented at 1:02 PM on September 13, 2023:
Or skip/ignore this particular test.
fanquake
commented at 3:09 PM on September 13, 2023:
member
Tracking down what looks like the final issue, in test_bitcoin.dbg. Building with this branch, https://github.com/fanquake/bitcoin/tree/gcc_12_debug, which excludes the two problematic options, I see a diff in the debug symbols. Note that the diff isn't as big as the difference in addresses makes it seem:
diff --git a/c.txt b/c.txt
index 85e71d2..45615e3 100644
--- a/c.txt
+++ b/c.txt
@@ -11,30 +11,28 @@
[0x0019028c] Special opcode 32: advance Address by 8 to 0x1e7d34 and Line by -1 to 72
[0x0019028d] Set column to 27
[0x0019028f] Copy (view 1)
- [0x00190290] Set column to 28
+ [0x00190290] Set column to 23
[0x00190292] Set is_stmt to 0
[0x00190293] Special opcode 6: advance Address by 0 to 0x1e7d34 and Line by 1 to 73 (view 2)
- [0x00190294] Set column to 23
- [0x00190296] Special opcode 19: advance Address by 4 to 0x1e7d38 and Line by 0 to 73
- [0x00190297] Set column to 9
- [0x00190299] Set is_stmt to 1
- [0x0019029a] Special opcode 60: advance Address by 16 to 0x1e7d48 and Line by -1 to 72
- [0x0019029b] Set column to 27
- [0x0019029d] Copy (view 1)
- [0x0019029e] Set is_stmt to 0
- [0x0019029f] Special opcode 47: advance Address by 12 to 0x1e7d54 and Line by 0 to 72
- [0x001902a0] Set column to 37
- [0x001902a2] Advance Line by 97 to 169
- [0x001902a5] Copy (view 1)
- [0x001902a6] Set column to 33
- [0x001902a8] Special opcode 19: advance Address by 4 to 0x1e7d58 and Line by 0 to 169
- [0x001902a9] Set column to 37
- [0x001902ab] Special opcode 19: advance Address by 4 to 0x1e7d5c and Line by 0 to 169
- [0x001902ac] Set column to 26
- [0x001902ae] Special opcode 19: advance Address by 4 to 0x1e7d60 and Line by 0 to 169
- [0x001902af] Set is_stmt to 1
- [0x001902b0] Special opcode 47: advance Address by 12 to 0x1e7d6c and Line by 0 to 169
- [0x001902b1] Set column to 37
- [0x001902b3] Set is_stmt to 0
- [0x001902b4] Copy (view 1)
- [0x001902b5] Set column to 33
+ [0x00190294] Set column to 9
+ [0x00190296] Set is_stmt to 1
+ [0x00190297] Special opcode 74: advance Address by 20 to 0x1e7d48 and Line by -1 to 72
+ [0x00190298] Set column to 27
+ [0x0019029a] Copy (view 1)
+ [0x0019029b] Set is_stmt to 0
+ [0x0019029c] Special opcode 47: advance Address by 12 to 0x1e7d54 and Line by 0 to 72
+ [0x0019029d] Set column to 37
+ [0x0019029f] Advance Line by 97 to 169
+ [0x001902a2] Copy (view 1)
+ [0x001902a3] Set column to 33
+ [0x001902a5] Special opcode 19: advance Address by 4 to 0x1e7d58 and Line by 0 to 169
+ [0x001902a6] Set column to 37
+ [0x001902a8] Special opcode 19: advance Address by 4 to 0x1e7d5c and Line by 0 to 169
+ [0x001902a9] Set column to 26
+ [0x001902ab] Special opcode 19: advance Address by 4 to 0x1e7d60 and Line by 0 to 169
+ [0x001902ac] Set is_stmt to 1
+ [0x001902ad] Special opcode 47: advance Address by 12 to 0x1e7d6c and Line by 0 to 169
+ [0x001902ae] Set column to 37
+ [0x001902b0] Set is_stmt to 0
+ [0x001902b1] Copy (view 1)
+ [0x001902b2] Set column to 33
fanquake force-pushed on Sep 20, 2023
fanquake force-pushed on Oct 2, 2023
Retropex referenced this in commit 3916135aee on Oct 4, 2023
Retropex referenced this in commit 5f62ed90f6 on Oct 4, 2023
PastaPastaPasta referenced this in commit 7675bd4fa1 on Oct 11, 2023
fanquake added this to the milestone 27.0 on Oct 23, 2023
PastaPastaPasta referenced this in commit d8cf7655ba on Oct 27, 2023
fanquake force-pushed on Nov 9, 2023
fanquake force-pushed on Nov 13, 2023
fanquake force-pushed on Nov 13, 2023
fanquake force-pushed on Nov 22, 2023
fanquake force-pushed on Nov 29, 2023
maflcko
commented at 7:05 PM on November 29, 2023:
member
What is the easiest way in guix to bisect gcc?
I will post a guide for doing this.
:eye: :eyes: :eyeglasses:
PastaPastaPasta referenced this in commit 65141f80ae on Dec 6, 2023
maflcko
commented at 6:36 PM on December 14, 2023:
member
Did you also try gcc-13.2, which may be an alternative at this point?
fanquake
commented at 7:04 PM on December 14, 2023:
member
Yes, iirc. I'll get back to this now that it's becoming more of a blocker. I've been sick of continually dealing with/having to track down problems in gui and similar non-critical code, when it comes to these kinds of changes (i.e LLVM bump also blocked on the GUI).
fanquake force-pushed on Dec 18, 2023
fanquake force-pushed on Jan 2, 2024
hebasto
commented at 10:21 AM on January 3, 2024:
member
$ env HOSTS=x86_64-apple-darwin ./contrib/guix/guix-build
...
make: Entering directory '/bitcoin/depends'
Extracting native_libtapi...
/bitcoin/depends/sources/eb33a59f2e30ff9724dc1ea8bee8b5229b0557c9.tar.gz: OK
Preprocessing native_libtapi...
patching file build.sh
Configuring native_libtapi...
Building native_libtapi...
-- The C compiler identification is Clang 17.0.6
-- The CXX compiler identification is Clang 17.0.6
-- The ASM compiler identification is Clang with GNU-like command-line
-- Found assembler: /home/hebasto/.guix-profile/bin/clang
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /home/hebasto/.guix-profile/bin/clang - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /home/hebasto/.guix-profile/bin/clang++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- clang project is enabled
-- clang-tools-extra project is disabled
-- compiler-rt project is disabled
-- debuginfo-tests project is disabled
-- libc project is disabled
-- libclc project is disabled
-- libcxx project is disabled
-- libcxxabi project is disabled
-- libunwind project is disabled
-- lld project is disabled
-- lldb project is disabled
-- mlir project is disabled
-- openmp project is disabled
-- parallel-libs project is disabled
-- polly project is disabled
-- pstl project is disabled
-- tapi project is enabled
-- flang project is disabled
-- Performing Test LLVM_LIBSTDCXX_MIN
-- Performing Test LLVM_LIBSTDCXX_MIN - Success
-- Performing Test LLVM_LIBSTDCXX_SOFT_ERROR
-- Performing Test LLVM_LIBSTDCXX_SOFT_ERROR - Failed
CMake Error at cmake/modules/CheckCompilerVersion.cmake:119 (message):
libstdc++ version should be at least 5.1 because LLVM will soon use new C++
features which your toolchain version doesn't support. You can temporarily
opt out using LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN, but very soon your
toolchain won't be supported.
Call Stack (most recent call first):
cmake/config-ix.cmake:14 (include)
CMakeLists.txt:691 (include)
-- Configuring incomplete, errors occurred!
See also "/bitcoin/depends/work/build/x86_64-apple-darwin/native_libtapi/eb33a59f2e30ff9724dc1ea8bee8b5229b0557c9-860be6e1562/build/CMakeFiles/CMakeOutput.log".
See also "/bitcoin/depends/work/build/x86_64-apple-darwin/native_libtapi/eb33a59f2e30ff9724dc1ea8bee8b5229b0557c9-860be6e1562/build/CMakeFiles/CMakeError.log".
make: *** [funcs.mk:291: /bitcoin/depends/work/build/x86_64-apple-darwin/native_libtapi/eb33a59f2e30ff9724dc1ea8bee8b5229b0557c9-860be6e1562/./.stamp_built] Error 1
make: Leaving directory '/bitcoin/depends'
fanquake
commented at 3:28 PM on January 5, 2024:
member
Drafting this until (may rebase on top of) #21778, which fixes the macOS build failures by just deleting the offending code.
fanquake marked this as a draft on Jan 5, 2024
DrahtBot added the label CI failed on Jan 13, 2024
fanquake removed this from the milestone 27.0 on Feb 1, 2024
fanquake force-pushed on Feb 22, 2024
DrahtBot removed the label CI failed on Feb 22, 2024
fanquake force-pushed on Mar 7, 2024
maflcko added the label DrahtBot Guix build requested on Mar 12, 2024
Retain native GCC 10 toolchain for macOS, to prevent compile failures in
native tools (this will be removed entirely when we tansition to LLD).
Update the vmov-alignment patch, for changes in GCC 12.
001412a4d2
guix: temporarily disable powerpcle taget
There non-determinism issues when compiling for this target across
x86_64 and aarch64.
10d56530e0
fanquake force-pushed on Mar 12, 2024
fanquake marked this as ready for review on Mar 12, 2024
fanquake
commented at 6:10 PM on March 12, 2024:
member
theuni
commented at 6:16 PM on March 12, 2024:
member
Re- Concept ACK.
Removing ppcle for now is less than ideal, but it's not worth having as a blocker for basically all pending toolchain/c++20 work.
Only suggestion is: Are there any upstream non-determinism bug reports we can link to? If not, IMO we should file them so the knowledge exists somewhere other than in your head :)
fanquake
commented at 6:20 PM on March 12, 2024:
member
(copying what I added to the PR description)
Temporarily disables the powerpc64le-linux-gnu target due to non-determinism issues when building across aarch64 and x86_64. Trying to fix the non-determinism was going to require trying to selectively disable optimization flags, which is already not ideal (and didn't fix all issues), and the migration to GCC 12 as our release compiler is now the blocker for multiple other (c++20 and similar) changes, so leaving this blocked on the powerpc64le binaries does not seem like a good tradeoff.
Are there any upstream non-determinism bug reports we can link to?
Not yet. We still need to minify a reproducer, which is also non-trivial. I will work on doing that, but also don't want it as a blocker to moving forward here.
fanquake
commented at 7:15 PM on March 12, 2024:
member
This is a metadata mirror of the GitHub repository
bitcoin/bitcoin.
This site is not affiliated with GitHub.
Content is generated from a GitHub metadata backup.
generated: 2026-04-22 18:13 UTC
This site is hosted by @0xB10C More mirrored repositories can be found on mirror.b10c.me
