| Age | Commit message (Collapse) | Author |
|---|
|
This commit backports a patch to the GCC 10.3.0 we build for Windows
cross-compilation in Guix. The commit has been backported to the GCC
releases/gcc-10 branch, but hasn't yet made it into a release.
The patch corrects a regression from an earlier GCC commit, see:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=357c4350680bf29f0c7a115424e3da11c53b5582
and
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=074226d5aa86cd3de517014acfe34c7f69a2ccc7,
related to the way newer versions of mingw-w64 implement setjmp/longjmp.
Ultimately this was causing a crash for us when Windows users were
viewing the network traffic tab inside the GUI. After some period, long
enough that a buffer would need reallocating, a call into FreeTypes
gray_record_cell() would result in a call to ft_longjmp (longjmp), which
would then trigger a crash.
Fixes: https://github.com/bitcoin-core/gui/issues/582.
See also:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=e8d1ca7d2c344a411779892616c423e157f4aea8.
https://bugreports.qt.io/browse/QTBUG-93476.
Github-Pull: #24842
Rebased-From: 457148a803cee02897b7428fa7b3eb93eed71e4c
|
|
This introduces a patch to our GCC (10.3.0) mingw-w64 compiler, in Guix, to make
it avoid using aligned vmov instructions. This works around a longstanding issue
in GCC, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412, which was recently
discovered to be causing issues, see #24726.
Note that distros like Debian are also patching around this issue, and that is
where this patch comes from. This would also explain why we haven't run into this
problem earlier, in development builds. See:
https://salsa.debian.org/mingw-w64-team/gcc-mingw-w64/-/blob/master/debian/patches/vmov-alignment.patch.
Fixes #24726.
Alternative to #24727.
See also:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939559
Github-Pull: #24736
Rebased-From: d6fae988eff78e28756d9b6219ec0239c420f51b
|
|
Our patch is now used upstream.
|
|
This currently points to the version-1.4.0 branch.
|
|
We use these flags in our test-security-check make target, but they are
only available because debian patches them in.
We can patch them in for our Guix builds so that we can check the sanity
of our security/symbol checking suite before running them.
|
|
|
|
Support for riscv64 in glibc landed in 2.27 so it's unavoidable that we
use 2.27.
Running a Bitcoin build with toolchains based on 2.24 for platforms
other than riscv64 seem to produce binaries which do not have 2.17
symbols. So use 2.24 since it's more recent and maintained by Debian
Stretch.
|
|
Otherwise the resulting .a static libraries (e.g. libstdc++.a) will not
be reproducible and end up making the Bitcoin binaries non-reproducible
as well.
See: https://reproducible-builds.org/docs/archives/#gnu-libtool
|
|
|
|
When building nsis, if VERSION is not specified, it defaults to
cvs_version which is non-deterministic as it includes the current date.
This patches nsis to default to SOURCE_DATE_EPOCH if it exists so that
nsis is reproducible.
Upstream change: https://github.com/kichik/nsis/pull/13
|
