This works around an issue when trying to use std::filesystem::remove_all
with the ARM GCC on Buster. Has been split out of #20744.
See commentary starting here: #20744 (comment). Also: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93201.
This works around an issue when trying to use std::filesystem::remove_all
with the ARM GCC on Buster. Has been split out of #20744.
See commentary starting here: #20744 (comment). Also: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93201.
This works around an issue when trying to use `std::filesystem::remove_all`
with the ARM GCC on Buster. Has been split out of #20744.
See comments starting here:
https://github.com/bitcoin/bitcoin/pull/20744#issuecomment-810279549.
Also: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93201.
We currently use gcc 8.4 for the arm guix builds. Should this be bumped to gcc 10.3?
To match the base GCC in Buster it’d be 10.2, however if we were doing this, I don’t think it should be part of this PR. Maybe another PR separate from #20744 that takes care of the more involved build system changes. There is at least some Guix changes required for the Windows build as well.
cr ACK 252d1a70fb452893efe4ab64298139eb08d8ac98
Buster is on gcc 8.3, and it doesn’t look like they are going to bump to 8.4 any time soon, so moving to the next debian release seems ok.
Buster is on gcc 8.3, and it doesn’t look like they are going to bump to 8.4 any time soon, so moving to the next debian release seems ok.
Yes, GCC-8 on Buster was bumped from 8.2 to 8.3 in Feb 2019, and received it’s last update in April 2019.
Labels
Tests