release: Guix 1.4.0 & GCC 10.3 #23778
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Concept ACK. |
|
Concept ACK the bug we ran into earlier was fixed in 10.3 (https://github.com/gcc-mirror/gcc/blob/releases/gcc-10.3.0/gcc/testsuite/gcc.dg/memcmp-pr95189.c) and 11.1 (https://github.com/gcc-mirror/gcc/blob/releases/gcc-11.1.0/gcc/testsuite/gcc.dg/memcmp-pr95189.c). So in theory we could also bump to 11.2 (to avoid another bump later), if there are no downsides doing it now. (unrelated) Depressingly, debian doesn't update its compilers. For reference on what major distros ship by default:
|
|
Concept ACK |
|
On Ubuntu 21.04: |
Getting this same error at the same step as @hebasto with Pop 21.10 (Based on Ubuntu 21.10). |
|
Big Concept ACK. I'll take a run at looking at this in the next few days. |
|
For the |
Thanks for posting! Followed the workaround there by pulling the And then EDIT: Just also want to mention I dropped trying to use the apt version and just went with one of the more official ways of installation (in my case, the installer script) |
|
Ok so here is my output: Some of the builds differ on my side: diff --git a/fanquake-guix.txt b/dunxen-guix.txt
index 2fb00dc..f0e7aed 100644
--- a/fanquake-guix.txt
+++ b/dunxen-guix.txt
@@ -1,28 +1,28 @@
-9d8d526b685606bfe0bd1eefce9fb9e49a734b922a58abb6f52aa2bb635ff611 guix-build-60e364ce1647/output/aarch64-linux-gnu/SHA256SUMS.part
+2e3fe1ef8ae518c381b7e449aada9f6e564efffcf7c989a7d81397a1efb37bd0 guix-build-60e364ce1647/output/aarch64-linux-gnu/SHA256SUMS.part
aa32b3f169966bbbf478ba2abb3d8c33c47341603b1a08493257a84eebd90316 guix-build-60e364ce1647/output/aarch64-linux-gnu/bitcoin-60e364ce1647-aarch64-linux-gnu-debug.tar.gz
-0a8822641111d1bb06bf068cbcf7b57156f2bd5a7ed09edbb73f3e9a69c4264e guix-build-60e364ce1647/output/aarch64-linux-gnu/bitcoin-60e364ce1647-aarch64-linux-gnu.tar.gz
-15660a12cd009c77f0b4d7b96f8b62153ba4e72daec21d5d6b95531e72ea1b23 guix-build-60e364ce1647/output/arm-linux-gnueabihf/SHA256SUMS.part
+6ac9305ee4c699c883869bf55e92540d5f9ccb452b6de14f520340b63a163a9e guix-build-60e364ce1647/output/aarch64-linux-gnu/bitcoin-60e364ce1647-aarch64-linux-gnu.tar.gz
+1b73826f82b512374c52d393894b343a83743aa26cacb73af8e9c5975692553b guix-build-60e364ce1647/output/arm-linux-gnueabihf/SHA256SUMS.part
53a3b6800d888d66a21a145146f2ddbe4121fb660d2f7357a4f969c3805ff05c guix-build-60e364ce1647/output/arm-linux-gnueabihf/bitcoin-60e364ce1647-arm-linux-gnueabihf-debug.tar.gz
-9b133b525a64b5f1c10c48eb740678e9f44eda682efe1c68feeff00d4c839564 guix-build-60e364ce1647/output/arm-linux-gnueabihf/bitcoin-60e364ce1647-arm-linux-gnueabihf.tar.gz
+200a0b241d81a214cc50ed6da4f2dd3804bbe8cf949e02f998dab787ec8e3239 guix-build-60e364ce1647/output/arm-linux-gnueabihf/bitcoin-60e364ce1647-arm-linux-gnueabihf.tar.gz
ad10ae1d69414deb7447f1839a027d09382ca40cdfb2a3600408b8a8689788dc guix-build-60e364ce1647/output/dist-archive/bitcoin-60e364ce1647.tar.gz
-18099ff26d228071ec3f5537dfd77aa8b9471b952d99a4c3419879e5edcfd2cf guix-build-60e364ce1647/output/powerpc64-linux-gnu/SHA256SUMS.part
+4f4d7095e465c8c008244b99db13e72fb601fd292bee8a18da9a870f9a1c9d92 guix-build-60e364ce1647/output/powerpc64-linux-gnu/SHA256SUMS.part
50763ded4fe0ff822bcbc8b46f2943e37082600b47f918952e5f41c70428b509 guix-build-60e364ce1647/output/powerpc64-linux-gnu/bitcoin-60e364ce1647-powerpc64-linux-gnu-debug.tar.gz
-6a24ab806e4a57c26d1b7f1bfbfa60ab370ef25a5f000d7ec9c3d394d63a699c guix-build-60e364ce1647/output/powerpc64-linux-gnu/bitcoin-60e364ce1647-powerpc64-linux-gnu.tar.gz
-353209e60e464dfdef754fe4cf468bed446146ca3ad84c30be48faa8d8736607 guix-build-60e364ce1647/output/powerpc64le-linux-gnu/SHA256SUMS.part
+fac500cb989510f7bd0a5818342f3967a62462e0c3cbc128947ea362cb78e373 guix-build-60e364ce1647/output/powerpc64-linux-gnu/bitcoin-60e364ce1647-powerpc64-linux-gnu.tar.gz
+13c4acbe636ba0b2dfd712d602cc3e69057e6d2a3ff8521315a3ac27913fdf6c guix-build-60e364ce1647/output/powerpc64le-linux-gnu/SHA256SUMS.part
8c4ba03ebc57ab4fbde4cdb84dde7232d45546d72bd0b09fdacbb76204268d80 guix-build-60e364ce1647/output/powerpc64le-linux-gnu/bitcoin-60e364ce1647-powerpc64le-linux-gnu-debug.tar.gz
-85436b2d1541b522de4b122d7e4494dbf16bb02e1aa72d08e82fcc22113b62b1 guix-build-60e364ce1647/output/powerpc64le-linux-gnu/bitcoin-60e364ce1647-powerpc64le-linux-gnu.tar.gz
-f03a92eb856fffa71b6246f5b2b37c17caf2372c891d75c36ad3dc30329b5d93 guix-build-60e364ce1647/output/riscv64-linux-gnu/SHA256SUMS.part
+070b1c3bce411587d1cebe3f8736ba7ad865fa9c12dec646669d7197bacf8132 guix-build-60e364ce1647/output/powerpc64le-linux-gnu/bitcoin-60e364ce1647-powerpc64le-linux-gnu.tar.gz
+22d40c0c1c609f0eaeee7eb4598c79ad08afb7a49a0810c3ffba477436f89cb0 guix-build-60e364ce1647/output/riscv64-linux-gnu/SHA256SUMS.part
846ffc31148f4ead460ab09577f279c1b8fe95f70c9cfc43d6c66729ca4f8e96 guix-build-60e364ce1647/output/riscv64-linux-gnu/bitcoin-60e364ce1647-riscv64-linux-gnu-debug.tar.gz
-aaa5325b80fabf85c20d409dc6f960155d815b3b450bebf7e57d484b0964383d guix-build-60e364ce1647/output/riscv64-linux-gnu/bitcoin-60e364ce1647-riscv64-linux-gnu.tar.gz
+60b6e7487ec16d76bf43eeeaa7896e97b0d22e7b47ac6a8695030ce23899f5bc guix-build-60e364ce1647/output/riscv64-linux-gnu/bitcoin-60e364ce1647-riscv64-linux-gnu.tar.gz
b8205fb01044ba08af0116c4e91c926f1e2260d0e3008ae3e8ee70208809be97 guix-build-60e364ce1647/output/x86_64-apple-darwin/SHA256SUMS.part
0bb2565cfb6dfad1c8f74a48d074d1a66bfbd9f2accfcc53e75f99bdef634448 guix-build-60e364ce1647/output/x86_64-apple-darwin/bitcoin-60e364ce1647-osx-unsigned.dmg
cc450a02ea3410971f115018424acf0dfc9d75c3d79127bee9aea95c5a028df7 guix-build-60e364ce1647/output/x86_64-apple-darwin/bitcoin-60e364ce1647-osx-unsigned.tar.gz
192e6b5cddcaf11c540d4389e843eaf5fa8185a5224f141883dc8f1f91c8d1d7 guix-build-60e364ce1647/output/x86_64-apple-darwin/bitcoin-60e364ce1647-osx64.tar.gz
-015be75ef1625c0f6621a1cfe60f0bddfefd3b974d1c9e79e9a314fcd463d533 guix-build-60e364ce1647/output/x86_64-linux-gnu/SHA256SUMS.part
+a3521975527b56a1c62a0209da48dd405836dd31690d3d9e7b35e6fe07f04ed7 guix-build-60e364ce1647/output/x86_64-linux-gnu/SHA256SUMS.part
1071dcbfe638ed34524e6b34bed8a721260002ba7bd5460879d6cb1b431aef75 guix-build-60e364ce1647/output/x86_64-linux-gnu/bitcoin-60e364ce1647-x86_64-linux-gnu-debug.tar.gz
-2dfbd9373861421857aa3d4e4ee091e0179ca41334d238c8523f6595caa70034 guix-build-60e364ce1647/output/x86_64-linux-gnu/bitcoin-60e364ce1647-x86_64-linux-gnu.tar.gz
-cb3d7ea3848f84541b91a6672b6c80bf9f2513741fc23de51cab1b3f23ddb2ae guix-build-60e364ce1647/output/x86_64-w64-mingw32/SHA256SUMS.part
-d465ce79d202df4c0b33451aaf716455a28ca515ce163d72ed65450525048984 guix-build-60e364ce1647/output/x86_64-w64-mingw32/bitcoin-60e364ce1647-win-unsigned.tar.gz
+242c3a93574bbb45eae64f0a39155aa610e4c13c13e593a447f34bb7ea09b4b7 guix-build-60e364ce1647/output/x86_64-linux-gnu/bitcoin-60e364ce1647-x86_64-linux-gnu.tar.gz
+d3fa57b4aac4926166626eccb105cce3ca0ac43158613e724cda8bd456871086 guix-build-60e364ce1647/output/x86_64-w64-mingw32/SHA256SUMS.part
+6f9960c0d545189d516f059c172e8ade07ac955cfb5f37b58fa876d40193e9f8 guix-build-60e364ce1647/output/x86_64-w64-mingw32/bitcoin-60e364ce1647-win-unsigned.tar.gz
65ddd96e902acd2cf3e082e4a32121263f2156a01a12d204732f6d06be74c9ff guix-build-60e364ce1647/output/x86_64-w64-mingw32/bitcoin-60e364ce1647-win64-debug.zip
-0626f22b0db3f480c81c70e200f5514d05e5520ed09c33da4b111e66878ea7b4 guix-build-60e364ce1647/output/x86_64-w64-mingw32/bitcoin-60e364ce1647-win64-setup-unsigned.exe
-d7d44954aa5708ecd6263a2b73ed79dc30707826ed70b7552d15d227c39d1e4d guix-build-60e364ce1647/output/x86_64-w64-mingw32/bitcoin-60e364ce1647-win64.zip
+6722097a72daede1a3b79d292100969fe53f7af152af9d9e86d9a2874f6e9bcd guix-build-60e364ce1647/output/x86_64-w64-mingw32/bitcoin-60e364ce1647-win64-setup-unsigned.exe
+4fbb369907d5ba1e1286508e7dbab8faab3f091dd42705c75e693bb5267f026e guix-build-60e364ce1647/output/x86_64-w64-mingw32/bitcoin-60e364ce1647-win64.zip |
|
@dunxen What if you re-run Guix builds after |
Building again after that! |
Hmm, looks like I'm getting the same outputs as I did earlier. |
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ConflictsReviewers, this pull request conflicts with the following ones:
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. |
Fixed in upstream: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=e89f767ce8990f4959616031e3c98fbfe92a008b |
|
With guix 1.1 and 1.2, I am running into: |
|
Upgraded to 1.3 to fix the segmentation fault. Mine match with @dunxen , but mismatch @fanquake |
Guix builds: |
hebasto
reviewed
Dec 27, 2021
|
I've rebased this on master, and updated our time-machine commit to be the HEAD of the Looking at the discussion on the Guix mailing list, it would seem that the aim is for version 1.4.0 to be released at the end of January. Which means even if we merged this PR prior to then (pointing to the tip of the 1.4.0 branch), we would be able to update our time machine to point to an "official" 1.4.0 release tag prior to our release (even accounting for some slippage on their end). In regards to the discussion on building this branch with Guix 1.1.0 & 1.2.0, and potentially pointing to an upstream commit to accommodate that: #23778 (comment). Aside from the fact that I'd rather not point to a near random commit on master, according to the latest mailing list discussion, the 1.4.0 release branch will be rebased on master before release, so it will include the e89f767ce8990f4959616031e3c98fbfe92a008b commit. Regardless of that, from what I've seen in testing, you can still build this branch starting with a Guix 1.2.0 installation (haven't yet tested 1.1.0), if you Some comments in regards to the actual changes:
Builds I've tested (some were done using Alpine 3.15, bash-5.1# find guix-build-$(git rev-parse --short=12 HEAD)/output/ -type f -print0 | env LC_ALL=C sort -z | xargs -r0 sha256sum
7a492106c502770705824a9847a681fefd0053785bb8a7faf15f8ff18f43720c guix-build-6d3d30a2c98b/output/aarch64-linux-gnu/SHA256SUMS.part
bc816ec471e7afb831e6e0cd93f35aa1a46408ca7dd65034065df89e63304ec4 guix-build-6d3d30a2c98b/output/aarch64-linux-gnu/bitcoin-6d3d30a2c98b-aarch64-linux-gnu-debug.tar.gz
d2d9aab247889e12aa438a7c77bd290a628518db72f29ad5c48bb22cd03808e1 guix-build-6d3d30a2c98b/output/aarch64-linux-gnu/bitcoin-6d3d30a2c98b-aarch64-linux-gnu.tar.gz
0671cb6382e884d3c9df7c32edfc8f8b12a753e8b3ce22c9e4c34264452dbcc3 guix-build-6d3d30a2c98b/output/arm-linux-gnueabihf/SHA256SUMS.part
4967a9f45a1ec2600a28e173dbbab8ffd379c4ee66a98b261029af50b7ba65bc guix-build-6d3d30a2c98b/output/arm-linux-gnueabihf/bitcoin-6d3d30a2c98b-arm-linux-gnueabihf-debug.tar.gz
3c30f0e50de7284f079f3ff1102225c05ed1e9df11d0f72e1f2b5643a17cf90f guix-build-6d3d30a2c98b/output/arm-linux-gnueabihf/bitcoin-6d3d30a2c98b-arm-linux-gnueabihf.tar.gz
02e80677bfcacc3bf5c4459a80a204dc76a62ba111ce439007e38ee86c7ca794 guix-build-6d3d30a2c98b/output/dist-archive/bitcoin-6d3d30a2c98b.tar.gz
d0be0c98469abfab71213643df3db7d08cc2f66fe2498b9565310e1f457b3f34 guix-build-6d3d30a2c98b/output/powerpc64-linux-gnu/SHA256SUMS.part
b9c598375979e767b7f6fa57cbf0c05229ccd8002c32a9e767bb27d266951b2c guix-build-6d3d30a2c98b/output/powerpc64-linux-gnu/bitcoin-6d3d30a2c98b-powerpc64-linux-gnu-debug.tar.gz
d88d163752433cb2832a5c5209979b398f94570e89fed8b3f678dc22db400161 guix-build-6d3d30a2c98b/output/powerpc64-linux-gnu/bitcoin-6d3d30a2c98b-powerpc64-linux-gnu.tar.gz
b52adf2912d3c8a15ecd148aa2431b4d26f6a6e7ae3cb9eaf29751c204cf738c guix-build-6d3d30a2c98b/output/powerpc64le-linux-gnu/SHA256SUMS.part
850a0b8a319dc6a9e4c07e70c32691ac7f3d711dc40c79d701a561028df55569 guix-build-6d3d30a2c98b/output/powerpc64le-linux-gnu/bitcoin-6d3d30a2c98b-powerpc64le-linux-gnu-debug.tar.gz
76d140e6184d5627f32a0caeac560da443f5b4eecba32e73f0d7c8691546ae8b guix-build-6d3d30a2c98b/output/powerpc64le-linux-gnu/bitcoin-6d3d30a2c98b-powerpc64le-linux-gnu.tar.gz
47786faae645781394c6533e92c76e929f8494d7ba1ce8a2eb77e6b5480b5810 guix-build-6d3d30a2c98b/output/riscv64-linux-gnu/SHA256SUMS.part
817bc8d3af82ce9b05d52b21b776b16c7b5f6b15f36620a1b3e5ff12a8f818a5 guix-build-6d3d30a2c98b/output/riscv64-linux-gnu/bitcoin-6d3d30a2c98b-riscv64-linux-gnu-debug.tar.gz
b115f6e75ef1518f713fbd25a76d029b1d65ceaaac715c66aa16f13120e3f5b0 guix-build-6d3d30a2c98b/output/riscv64-linux-gnu/bitcoin-6d3d30a2c98b-riscv64-linux-gnu.tar.gz
ed664c5a6e41e0cf7cd27d679fcec74e04d852e2e46a7adab70863b1409bcc24 guix-build-6d3d30a2c98b/output/x86_64-apple-darwin/SHA256SUMS.part
c82a90435825373996aa5a6f8fed58412a695cd136016cacde9096a4a329b108 guix-build-6d3d30a2c98b/output/x86_64-apple-darwin/bitcoin-6d3d30a2c98b-osx-unsigned.dmg
8d91a6c3f689d2691ed37474fa9a7b5a46c5301e87928944d771f16f7e4a6d5b guix-build-6d3d30a2c98b/output/x86_64-apple-darwin/bitcoin-6d3d30a2c98b-osx-unsigned.tar.gz
19b1a439450f827a670d84f0b716e95dd004004d315bfcb5b2f9adc6e7d375c9 guix-build-6d3d30a2c98b/output/x86_64-apple-darwin/bitcoin-6d3d30a2c98b-osx64.tar.gz
d17d8f628668bc63f46f786eb7c2c6b42dd7fa7a6cac536925b5cb2c59de4c74 guix-build-6d3d30a2c98b/output/x86_64-linux-gnu/SHA256SUMS.part
634718f123853f77bce42b719246499d86e4968b8059c1308c8315a8d980e55f guix-build-6d3d30a2c98b/output/x86_64-linux-gnu/bitcoin-6d3d30a2c98b-x86_64-linux-gnu-debug.tar.gz
cfbd97e6fd26882507d631bdf3d37a318dabf43f9578bfd888352d7cdadfcf00 guix-build-6d3d30a2c98b/output/x86_64-linux-gnu/bitcoin-6d3d30a2c98b-x86_64-linux-gnu.tar.gz
73541137d3ed73de1836d2a8bfffc2b7404527c107ce2f2b9bea314a9a01a176 guix-build-6d3d30a2c98b/output/x86_64-w64-mingw32/SHA256SUMS.part
d3ce42decb6a6df9640a5697a5de5b74c7f17d0d7c202158bd53a3eb066343b4 guix-build-6d3d30a2c98b/output/x86_64-w64-mingw32/bitcoin-6d3d30a2c98b-win-unsigned.tar.gz
cc7d50746f25e3a923078ce2ec68d6538972c8c2575dc3a908b394df08113e1d guix-build-6d3d30a2c98b/output/x86_64-w64-mingw32/bitcoin-6d3d30a2c98b-win64-debug.zip
a1f9ed25b9c773df8d8f863f71c1d856ad9d42262343be779437f68d2809d7df guix-build-6d3d30a2c98b/output/x86_64-w64-mingw32/bitcoin-6d3d30a2c98b-win64-setup-unsigned.exe
4aef01e4543f182eb345d327bf8ecc19872c38e46046ed530a6e6df4e28ab1d6 guix-build-6d3d30a2c98b/output/x86_64-w64-mingw32/bitcoin-6d3d30a2c98b-win64.zipDebian Bullseye, root@dc9ddd0ecfa4:/bitcoin# find guix-build-$(git rev-parse --short=12 HEAD)/output/ -type f -print0 | env LC_ALL=C sort -z | xargs -r0 sha256sum
7a492106c502770705824a9847a681fefd0053785bb8a7faf15f8ff18f43720c guix-build-6d3d30a2c98b/output/aarch64-linux-gnu/SHA256SUMS.part
bc816ec471e7afb831e6e0cd93f35aa1a46408ca7dd65034065df89e63304ec4 guix-build-6d3d30a2c98b/output/aarch64-linux-gnu/bitcoin-6d3d30a2c98b-aarch64-linux-gnu-debug.tar.gz
d2d9aab247889e12aa438a7c77bd290a628518db72f29ad5c48bb22cd03808e1 guix-build-6d3d30a2c98b/output/aarch64-linux-gnu/bitcoin-6d3d30a2c98b-aarch64-linux-gnu.tar.gz
0671cb6382e884d3c9df7c32edfc8f8b12a753e8b3ce22c9e4c34264452dbcc3 guix-build-6d3d30a2c98b/output/arm-linux-gnueabihf/SHA256SUMS.part
4967a9f45a1ec2600a28e173dbbab8ffd379c4ee66a98b261029af50b7ba65bc guix-build-6d3d30a2c98b/output/arm-linux-gnueabihf/bitcoin-6d3d30a2c98b-arm-linux-gnueabihf-debug.tar.gz
3c30f0e50de7284f079f3ff1102225c05ed1e9df11d0f72e1f2b5643a17cf90f guix-build-6d3d30a2c98b/output/arm-linux-gnueabihf/bitcoin-6d3d30a2c98b-arm-linux-gnueabihf.tar.gz
02e80677bfcacc3bf5c4459a80a204dc76a62ba111ce439007e38ee86c7ca794 guix-build-6d3d30a2c98b/output/dist-archive/bitcoin-6d3d30a2c98b.tar.gz
d0be0c98469abfab71213643df3db7d08cc2f66fe2498b9565310e1f457b3f34 guix-build-6d3d30a2c98b/output/powerpc64-linux-gnu/SHA256SUMS.part
b9c598375979e767b7f6fa57cbf0c05229ccd8002c32a9e767bb27d266951b2c guix-build-6d3d30a2c98b/output/powerpc64-linux-gnu/bitcoin-6d3d30a2c98b-powerpc64-linux-gnu-debug.tar.gz
d88d163752433cb2832a5c5209979b398f94570e89fed8b3f678dc22db400161 guix-build-6d3d30a2c98b/output/powerpc64-linux-gnu/bitcoin-6d3d30a2c98b-powerpc64-linux-gnu.tar.gz
b52adf2912d3c8a15ecd148aa2431b4d26f6a6e7ae3cb9eaf29751c204cf738c guix-build-6d3d30a2c98b/output/powerpc64le-linux-gnu/SHA256SUMS.part
850a0b8a319dc6a9e4c07e70c32691ac7f3d711dc40c79d701a561028df55569 guix-build-6d3d30a2c98b/output/powerpc64le-linux-gnu/bitcoin-6d3d30a2c98b-powerpc64le-linux-gnu-debug.tar.gz
76d140e6184d5627f32a0caeac560da443f5b4eecba32e73f0d7c8691546ae8b guix-build-6d3d30a2c98b/output/powerpc64le-linux-gnu/bitcoin-6d3d30a2c98b-powerpc64le-linux-gnu.tar.gz
47786faae645781394c6533e92c76e929f8494d7ba1ce8a2eb77e6b5480b5810 guix-build-6d3d30a2c98b/output/riscv64-linux-gnu/SHA256SUMS.part
817bc8d3af82ce9b05d52b21b776b16c7b5f6b15f36620a1b3e5ff12a8f818a5 guix-build-6d3d30a2c98b/output/riscv64-linux-gnu/bitcoin-6d3d30a2c98b-riscv64-linux-gnu-debug.tar.gz
b115f6e75ef1518f713fbd25a76d029b1d65ceaaac715c66aa16f13120e3f5b0 guix-build-6d3d30a2c98b/output/riscv64-linux-gnu/bitcoin-6d3d30a2c98b-riscv64-linux-gnu.tar.gz
d17d8f628668bc63f46f786eb7c2c6b42dd7fa7a6cac536925b5cb2c59de4c74 guix-build-6d3d30a2c98b/output/x86_64-linux-gnu/SHA256SUMS.part
634718f123853f77bce42b719246499d86e4968b8059c1308c8315a8d980e55f guix-build-6d3d30a2c98b/output/x86_64-linux-gnu/bitcoin-6d3d30a2c98b-x86_64-linux-gnu-debug.tar.gz
cfbd97e6fd26882507d631bdf3d37a318dabf43f9578bfd888352d7cdadfcf00 guix-build-6d3d30a2c98b/output/x86_64-linux-gnu/bitcoin-6d3d30a2c98b-x86_64-linux-gnu.tar.gz
73541137d3ed73de1836d2a8bfffc2b7404527c107ce2f2b9bea314a9a01a176 guix-build-6d3d30a2c98b/output/x86_64-w64-mingw32/SHA256SUMS.part
d3ce42decb6a6df9640a5697a5de5b74c7f17d0d7c202158bd53a3eb066343b4 guix-build-6d3d30a2c98b/output/x86_64-w64-mingw32/bitcoin-6d3d30a2c98b-win-unsigned.tar.gz
cc7d50746f25e3a923078ce2ec68d6538972c8c2575dc3a908b394df08113e1d guix-build-6d3d30a2c98b/output/x86_64-w64-mingw32/bitcoin-6d3d30a2c98b-win64-debug.zip
a1f9ed25b9c773df8d8f863f71c1d856ad9d42262343be779437f68d2809d7df guix-build-6d3d30a2c98b/output/x86_64-w64-mingw32/bitcoin-6d3d30a2c98b-win64-setup-unsigned.exe
4aef01e4543f182eb345d327bf8ecc19872c38e46046ed530a6e6df4e28ab1d6 guix-build-6d3d30a2c98b/output/x86_64-w64-mingw32/bitcoin-6d3d30a2c98b-win64.zipDebian Experimental, root@3b26b9608b88:/bitcoin# find guix-build-$(git rev-parse --short=12 HEAD)/output/ -type f -print0 | env LC_ALL=C sort -z | xargs -r0 sha256sum
b7f4fd2a889450453a840c87bc1059703acb358dc9b915930da2b53c9088cdb6 guix-build-6d3d30a2c98b/output/arm-linux-gnueabihf/SHA256SUMS.part
27f6e1e0b5751c822f134fcd0d1362629c5f7aba10c8a0a3431d3b65304e95b9 guix-build-6d3d30a2c98b/output/arm-linux-gnueabihf/bitcoin-6d3d30a2c98b-arm-linux-gnueabihf-debug.tar.gz
6b19eb04cc386d1bc8b3c26b04d0ce444dab2099b531d8d0629d71c9586af38f guix-build-6d3d30a2c98b/output/arm-linux-gnueabihf/bitcoin-6d3d30a2c98b-arm-linux-gnueabihf.tar.gz
02e80677bfcacc3bf5c4459a80a204dc76a62ba111ce439007e38ee86c7ca794 guix-build-6d3d30a2c98b/output/dist-archive/bitcoin-6d3d30a2c98b.tar.gz
a31aa931008faa588a65c1f8cc65a2e436f0605ca955facf99df51c46815aec8 guix-build-6d3d30a2c98b/output/powerpc64-linux-gnu/SHA256SUMS.part
7b0f2ef2510c80c9e76864e6f16e7e9303dedd5b5bd32750231607e7eb11b99a guix-build-6d3d30a2c98b/output/powerpc64-linux-gnu/bitcoin-6d3d30a2c98b-powerpc64-linux-gnu-debug.tar.gz
b5aeaf25cd85e64732a90c83f291bdc72b168f93b868313d38c8f77ad4b6726d guix-build-6d3d30a2c98b/output/powerpc64-linux-gnu/bitcoin-6d3d30a2c98b-powerpc64-linux-gnu.tar.gz
477f4035e86765f865034115d7c4f3214ec1b612a686e12200604f9ae3153de4 guix-build-6d3d30a2c98b/output/powerpc64le-linux-gnu/SHA256SUMS.part
f2428afe1da0d5103a9cf0e6a706d629b10d74f3fd72a76c17f121f84d6fe30e guix-build-6d3d30a2c98b/output/powerpc64le-linux-gnu/bitcoin-6d3d30a2c98b-powerpc64le-linux-gnu-debug.tar.gz
bae006b97bf257b8c63f1c79bb951668da3293a9dff88091c273169a8af4e88f guix-build-6d3d30a2c98b/output/powerpc64le-linux-gnu/bitcoin-6d3d30a2c98b-powerpc64le-linux-gnu.tar.gz
23b44e507e94a02565c7d11494288eafad85a038ad84f2618438fbae2cf05b40 guix-build-6d3d30a2c98b/output/riscv64-linux-gnu/SHA256SUMS.part
4abf58e1104f8adf4581643d2f5d82dcf3bd040d1a3a45126a9ff1875ed92608 guix-build-6d3d30a2c98b/output/riscv64-linux-gnu/bitcoin-6d3d30a2c98b-riscv64-linux-gnu-debug.tar.gz
5479c9fc8efed3bc792d1caba1315fad04f2d9e10bced26ffee9ce90c388bc7d guix-build-6d3d30a2c98b/output/riscv64-linux-gnu/bitcoin-6d3d30a2c98b-riscv64-linux-gnu.tar.gz
c88b24fe48d980ecc35321cdc50f42ea74bef1e8cdfd4cc75dd0212dd222b97d guix-build-6d3d30a2c98b/output/x86_64-linux-gnu/SHA256SUMS.part
648e05ae44e2810fc95493274509c134d221f70245d41c9e904aba33f0625a57 guix-build-6d3d30a2c98b/output/x86_64-linux-gnu/bitcoin-6d3d30a2c98b-x86_64-linux-gnu-debug.tar.gz
e4c104e29d616348c6292c63cf564923b8b590a7ce133ca3ecc5f4d2f0b521d2 guix-build-6d3d30a2c98b/output/x86_64-linux-gnu/bitcoin-6d3d30a2c98b-x86_64-linux-gnu.tar.gz
638f681b6762fb48dcb6f3fc74291353e0612c4db6c314da3132a87eff2d379f guix-build-6d3d30a2c98b/output/x86_64-w64-mingw32/SHA256SUMS.part
d3ce42decb6a6df9640a5697a5de5b74c7f17d0d7c202158bd53a3eb066343b4 guix-build-6d3d30a2c98b/output/x86_64-w64-mingw32/bitcoin-6d3d30a2c98b-win-unsigned.tar.gz
d049ff92a052533d62f657d2447a364774d332c114f2ffa3015bc604bf41ae90 guix-build-6d3d30a2c98b/output/x86_64-w64-mingw32/bitcoin-6d3d30a2c98b-win64-debug.zip
a1f9ed25b9c773df8d8f863f71c1d856ad9d42262343be779437f68d2809d7df guix-build-6d3d30a2c98b/output/x86_64-w64-mingw32/bitcoin-6d3d30a2c98b-win64-setup-unsigned.exe
314237d56f284d1a09a673e571cf6278ab3a44eab25d51723eb23badfd59d130 guix-build-6d3d30a2c98b/output/x86_64-w64-mingw32/bitcoin-6d3d30a2c98b-win64.zip |
Wouldn't it be an option to just commit |
I agree. My understanding is that the only reason the imagery generation is so complicated is to support forks of Bitcoin Core being able to adapt the imagery to their own branding via
I agree. The value of forks of Core being able to provide their own branding inside the .dmg, doesn't outweigh the additional complexity added to our build system to handle the generation of the imagery on demand (I would go as far as saying we don't need a "branded" .dmg at all). Dropping the imagery generation would remove build dependencies on In any case, those changes aren't going to be made in this PR, and the change here is to just revert to the C-based librsvg. |
|
At commit 84f9931 on Ubuntu 20.04 I also get the following hashes (which match hebastos): Upgrading Guix from 1.2 was quite a pain though, requiring some (seemingly undocumented) removals of the entire |
|
Guix hashes, mine match @hebasto and @willcl-ark |
|
My output (after 1713m55.801s build time Matches @jarolrod etc |
|
Given that I haven't seen any pushback in regards to making this change, and we've clearly got reproducibility, I'm going to go-ahead and merge this PR now. I'd like to unblock #20744, and also deal with #23846 by just removing the Boost code entirely, before it becomes an issue for more people building master. Note that if any issues do arise in regards to this change, for example, in regards to using GCC 10, it is very easy for us to switch to using a different version of GCC, without reverting all of the changes here, by changing our |
sidhujag
pushed a commit
to syscoin/syscoin
that referenced
this pull request
Jan 7, 2022
84f9931 guix: use upstream python-requests (2.26.0) (fanquake) 187dc1e build: use python-asn1crypto from upstream (fanquake) b1e8f0b guix: use uptream nsis-x86_64 (fanquake) 3ccfba1 guix: use GCC 10 (over GCC 8) to build releases (fanquake) Pull request description: Guix's `core-updates-frozen` branch has been merged back into `master`, and a [`version-1.4.0`](https://git.savannah.gnu.org/cgit/guix.git/log/?h=version-1.4.0) branch has been created. This is great, as it means the next Guix release is on the horizon, and it contains a number of changes I'd like to take advantage of. In particular, is migrating the version of GCC we use for releases from GCC 8 to GCC 10.3.0 (which is also the new Guix default GCC). This is my preferred method of unblocking progress in bitcoin#20744, which is currently stalled due to support for `std::filesystem` for Windows not arriving in GCC until version 9, whereas it's usable on Linux starting with GCC 8. The current set of changes in that PR [attempt to backport support](bitcoin@9604eda) for `std::filesystem`, for Windows, to GCC 8, similar to what is currently done by Debian, however that is somewhat convoluted, and using GCC 10 with our current Guix version would require updating at least one Guix patch to GCC, so is not completely straightforward either. Other changes included here: * Dropping our `--no-*` patch for mingw binutils ld, as we can take advantage of the `--disable-*` flags that are now available in binutlils 2.37. The security check tests are updated accordingly. * Dropping our current patch for NSIS, as it's been integrated upstream, however given we are building v3.05, we need a different one (kichik/nsis@229b613) for compiling against GCC 10. * Removing our `python-asn1crypto` package definition, as an identical package is available in Guix. Over time we should look at trying to get the rest of the python packages we define here upstreamed. * Adding a patch for `python-elfsteem` to fix an issue in the example code when using Python 3.9+. * Our base glibc (`2.24`) now inherits from glibc-2.31. Guix has removed packages of glibc < 2.29, and the current version of glibc is `2.33`. However glibc-2.31 is the newest version that still contains a workaround for installing sunrpc data, which we need, so inheriting from that version seemed like the most straightforward solution. * As mentioned, Guix has removed glibcs < 2.29, so we add our own package definition for glibc 2.27, which we use for our RISC-V toolchain (also inheriting from 2.31). The guix commit hash currently points to the head of the `version-1.4.0` branch. This can be updated to an official release tag when one is available. Looking for Concept ACKs on migrating to using GCC 10.3 for building releases. Keeping in mind issues like bitcoin#20005, however that particular bug should be fixed in GCC 10.3.0+, according to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95189. Guix Builds: ```bash bash-5.1# find guix-build-$(git rev-parse --short=12 HEAD)/output/ -type f -print0 | env LC_ALL=C sort -z | xargs -r0 sha256sum ea56ef38bd94dbcb11b9d10e2f10c205109daad03fea4313f79892fc497ba68d guix-build-84f9931cb449/output/aarch64-linux-gnu/SHA256SUMS.part 01123ab23e5a09dc06a897837389e859d302ba2b18fbe827936ec8983765e7df guix-build-84f9931cb449/output/aarch64-linux-gnu/bitcoin-84f9931cb449-aarch64-linux-gnu-debug.tar.gz 7a24e25c2237e5aeb14508b91c5c6954572814e1767e892c164494f32d73b0c0 guix-build-84f9931cb449/output/aarch64-linux-gnu/bitcoin-84f9931cb449-aarch64-linux-gnu.tar.gz 0e1dba0233da1f487222b128964980d50393e61a6971bcf4c71951c29fdf3993 guix-build-84f9931cb449/output/arm-linux-gnueabihf/SHA256SUMS.part 8cd4c6f42abc81427f1d2500f86daced2a4ee78882dd9d03b5a0211a1d96306e guix-build-84f9931cb449/output/arm-linux-gnueabihf/bitcoin-84f9931cb449-arm-linux-gnueabihf-debug.tar.gz c180db6bffb1a54b6dc65929d86d5eba9adf876a28ad320590ed230233e57299 guix-build-84f9931cb449/output/arm-linux-gnueabihf/bitcoin-84f9931cb449-arm-linux-gnueabihf.tar.gz 4efcda7b63646eb46dabea7122fb026f2c063d2919a9dcbbffbc0929b9c56ced guix-build-84f9931cb449/output/dist-archive/bitcoin-84f9931cb449.tar.gz 1e35e96034fed00674f362d6471fb402dd2758cec2860ded4fd7e37c38935a44 guix-build-84f9931cb449/output/powerpc64-linux-gnu/SHA256SUMS.part 96a0b7f54d3b3935c134f8c2aaaf11a314b54c9d7924ba751503caa16bd1c840 guix-build-84f9931cb449/output/powerpc64-linux-gnu/bitcoin-84f9931cb449-powerpc64-linux-gnu-debug.tar.gz ae05137b6fb3494120f5413bf8a94ca3c1b0c047e1f512e6c2c5a0b1f122f075 guix-build-84f9931cb449/output/powerpc64-linux-gnu/bitcoin-84f9931cb449-powerpc64-linux-gnu.tar.gz c22e5fbcdcdbfa5d385537e2c1dab55004d9e94396ebccef0bc3d216edfacbbe guix-build-84f9931cb449/output/powerpc64le-linux-gnu/SHA256SUMS.part 52602b41e81a921435d93f2a3ae29549aa65a4147cdbf1ed7d9e4a44c4dc902a guix-build-84f9931cb449/output/powerpc64le-linux-gnu/bitcoin-84f9931cb449-powerpc64le-linux-gnu-debug.tar.gz a2cc7e9385452163a7bda99f6f9aa630fd35d4ba13d4fd9a4dd7e8062206650d guix-build-84f9931cb449/output/powerpc64le-linux-gnu/bitcoin-84f9931cb449-powerpc64le-linux-gnu.tar.gz e75fadf1b1c7e4ae3d52e7a8051a881de17bd4d9d32c1ca29ca0ddbb8028ee51 guix-build-84f9931cb449/output/riscv64-linux-gnu/SHA256SUMS.part 3b643c33842a15befb5d36d13b598a5e628c11b95671336c8dea51b5eed9c79a guix-build-84f9931cb449/output/riscv64-linux-gnu/bitcoin-84f9931cb449-riscv64-linux-gnu-debug.tar.gz e9a1ee7451502508cde73dc300aca8a421e379ac08c3f4adaf8c768fbfa942ac guix-build-84f9931cb449/output/riscv64-linux-gnu/bitcoin-84f9931cb449-riscv64-linux-gnu.tar.gz c0508a0872cf1415a47983d2ebbc9e5a46282ce7b6453afac544e0d1315b7bf9 guix-build-84f9931cb449/output/x86_64-apple-darwin/SHA256SUMS.part 7c02267cb91e2649088af5e96f81142beaad67f6a1a0588355174a4157b31458 guix-build-84f9931cb449/output/x86_64-apple-darwin/bitcoin-84f9931cb449-osx-unsigned.dmg 46dbf5a911abfa63e3c5aa8440289da5fdea89da013253c08768ce58b798a99d guix-build-84f9931cb449/output/x86_64-apple-darwin/bitcoin-84f9931cb449-osx-unsigned.tar.gz ab2e2360f18cb1b80bfd37f1a9508a938e89237767120472f932402cc809f0eb guix-build-84f9931cb449/output/x86_64-apple-darwin/bitcoin-84f9931cb449-osx64.tar.gz f58aa000692f7ea09ab8e7ec159a806d3a665f0f70558e62a53d56afb361eb02 guix-build-84f9931cb449/output/x86_64-linux-gnu/SHA256SUMS.part 78a76aef8469b07a41588e019a6dfa890c36fd5becf2c8d73a71c9e72bcabde6 guix-build-84f9931cb449/output/x86_64-linux-gnu/bitcoin-84f9931cb449-x86_64-linux-gnu-debug.tar.gz 5e6e0040b37ff035de41c8fcfee5d498bd19fa489024704dd4caa0ab9f566450 guix-build-84f9931cb449/output/x86_64-linux-gnu/bitcoin-84f9931cb449-x86_64-linux-gnu.tar.gz d6e6af70f277d9c9ef9b4773ec05920355ac07ebec71ff3e179676047329964b guix-build-84f9931cb449/output/x86_64-w64-mingw32/SHA256SUMS.part 37f24f6899e7803ed07bd0f5eb3f0fb6237ac1254dd72f446e9e4e488a927c8e guix-build-84f9931cb449/output/x86_64-w64-mingw32/bitcoin-84f9931cb449-win-unsigned.tar.gz 14f7d1c14a5fc3b4c336d301f936c5578d6e31d61ec720dfc9d4129445d1e2a2 guix-build-84f9931cb449/output/x86_64-w64-mingw32/bitcoin-84f9931cb449-win64-debug.zip c8049dcc0308a76f21dd781e8561ebbafa84034fbf8e3afa7d4017866d7fd195 guix-build-84f9931cb449/output/x86_64-w64-mingw32/bitcoin-84f9931cb449-win64-setup-unsigned.exe fb1e6580c25b073118f121aabaa04aa09643bc97cfeaea7c9a24bbe65c33cbb6 guix-build-84f9931cb449/output/x86_64-w64-mingw32/bitcoin-84f9931cb449-win64.zip ``` ACKs for top commit: hebasto: re-ACK 84f9931 Tree-SHA512: 2f5f4f6bb1f55a048dba88523f235320e51c4af963355abf6a86b7035623b2100ae3dc44396c76fbeea89ae9cfbc5342abd3e2c41760ede8b689d7757d6e7f25
MarcoFalke
reviewed
Jan 8, 2022
| @@ -239,7 +239,7 @@ SOURCE_DATE_EPOCH="${SOURCE_DATE_EPOCH:-$(git -c log.showSignature=false log --f | |||
| time-machine() { | |||
| # shellcheck disable=SC2086 | |||
| guix time-machine --url=https://git.savannah.gnu.org/git/guix.git \ | |||
| --commit=aa34d4d28dfe25ba47d5800d05000fb7221788c0 \ | |||
| --commit=fa17abf1af09570708daa28dd40ffbc932ebe25c \ | |||
There was a problem hiding this comment.
What is the recommended way to review this? git diff aa34d4 fa17abf1 will print a lot of changes, most of which are unrelated to our build process.
cc @dongcarl
fanquake
added a commit
that referenced
this pull request
Jan 12, 2022
…4.0" branch a229451 build: Point Guix to the current top of the "version-1.4.0" branch (Hennadii Stepanov) Pull request description: On master (c561f2f) the commit in Guix repo from #23778 seems unavailable: ``` $ git checkout fa17abf1af09570708daa28dd40ffbc932ebe25c fatal: reference is not a tree: fa17abf1af09570708daa28dd40ffbc932ebe25c ``` This PR points Guix to the current top of the "version-1.4.0" branch. Fixes #24040. ACKs for top commit: MarcoFalke: Approach ACK a229451 fanquake: ACK a229451 - from what I've seen on the mailing list there shouldn't be any more force pushing. Tree-SHA512: c58f846fb0afd51b5c2dd33034e9d593aec5d5b49e9f2232af70ae1224da8408ad4e05aa314609350d92a6400e354a816b988226e3572198c3f839ab33913164
sidhujag
pushed a commit
to syscoin/syscoin
that referenced
this pull request
Jan 12, 2022
…sion-1.4.0" branch a229451 build: Point Guix to the current top of the "version-1.4.0" branch (Hennadii Stepanov) Pull request description: On master (c561f2f) the commit in Guix repo from bitcoin#23778 seems unavailable: ``` $ git checkout fa17abf1af09570708daa28dd40ffbc932ebe25c fatal: reference is not a tree: fa17abf1af09570708daa28dd40ffbc932ebe25c ``` This PR points Guix to the current top of the "version-1.4.0" branch. Fixes bitcoin#24040. ACKs for top commit: MarcoFalke: Approach ACK a229451 fanquake: ACK a229451 - from what I've seen on the mailing list there shouldn't be any more force pushing. Tree-SHA512: c58f846fb0afd51b5c2dd33034e9d593aec5d5b49e9f2232af70ae1224da8408ad4e05aa314609350d92a6400e354a816b988226e3572198c3f839ab33913164
giaki3003
added a commit
to SINOVATEblockchain/sinovate
that referenced
this pull request
Jan 28, 2022
…than generating e09773d build: use a static .tiff for macOS .dmg over generating (fanquake) Pull request description: For demonstration, after [discussion in bitcoin#23778](bitcoin#23778 (comment)), and the question as to why we can't just have a `background.tiff` that we copy into the macOS DMG, and do away with the somewhat convoluted image generation steps. From my understanding, the only reason we have this image generation as part of our build system is so that forks of Core can adapt the imagery for their own branding via `PACKAGE_NAME`. It don't think it provides much value to us, and could just have a static .tiff that we copy into the dmg (replacing the .svg that currently lives in macdeploy/). Doing this would eliminate the following build dependencies: For native macOS: * `sed` (usage in Makefile.am) * `librsvg` (rsvg-convert) * `tiffutil` Linux macOS cross-compile: * `sed` (usage in Makefille.am) * `librsvg` * `tiffcp` * `convert` (imagemagick) * `font-tuffy` Guix Build: ```bash bash-5.1# find guix-build-$(git rev-parse --short=12 HEAD)/output/ -type f -print0 | env LC_ALL=C sort -z | xargs -r0 sha256sum c98d67796863f4b1bab0ad600d46bd74e744d94072cbd4bc856a6aeaba3bb329 guix-build-e09773d20a92/output/dist-archive/bitcoin-e09773d20a92.tar.gz 3336f90bab312798cb7665e2b4ae24d1a270fb240647d5fed8dbfcd83e3ed37e guix-build-e09773d20a92/output/x86_64-apple-darwin/SHA256SUMS.part 8fd680c7ee158c64bad212385df7b0b302c6c2143d4e672b4b0eb5da41f9256d guix-build-e09773d20a92/output/x86_64-apple-darwin/bitcoin-e09773d20a92-osx-unsigned.dmg 34f54177c2f0700e8cfaf5d85d91e404807cd9d411e22006cdff82653e5f4af2 guix-build-e09773d20a92/output/x86_64-apple-darwin/bitcoin-e09773d20a92-osx-unsigned.tar.gz da6b8f54ef755d40330c8eac4f5bd0329637e827be9ee61318600d5d0bdcc3dc guix-build-e09773d20a92/output/x86_64-apple-darwin/bitcoin-e09773d20a92-osx64.tar.gz ```  ACKs for top commit: hebasto: ACK e09773d jarolrod: ACK e09773d Zero-1729: ACK e09773d Tree-SHA512: 0ad06699a5451daa8cfaaa46759eb7bd85254a72e23f857f70d433a2ffb1a4bf6dd464d9c4ac9f8c20aab045f4e2b61c6dcdcbcceef96ce515b1a0c501665b1f
fanquake
added a commit
to fanquake/bitcoin
that referenced
this pull request
Aug 5, 2022
With the release of binutils/ld 2.36, ld swapped to much improved default settings when producing windows binaries with mingw-w64. One of these changes was to stop stripping the .reloc section from binaries, which is required for working ASLR. .reloc section stripping is something we've accounted for previously, see bitcoin#18702. The related upstream discussion is in this thread: https://sourceware.org/bugzilla/show_bug.cgi?id=19011. When we switched to using a newer Guix time-machine in bitcoin#23778, we begun using binutils 2.37 to produce releases. Since then, our windows installer (produced with makensis) has not functioned correctly when run on a Windows system with the "Force randomization for images (Mandatory ASLR)" option enabled. Note that all of our other release binaries, which all contain .reloc sections, function fine under the same option.
fanquake
added a commit
to fanquake/bitcoin
that referenced
this pull request
Aug 5, 2022
With the release of binutils/ld 2.36, ld swapped to much improved default settings when producing windows binaries with mingw-w64. One of these changes was to stop stripping the .reloc section from binaries, which is required for working ASLR. .reloc section stripping is something we've accounted for previously, see bitcoin#18702. The related upstream discussion is in this thread: https://sourceware.org/bugzilla/show_bug.cgi?id=19011. When we switched to using a newer Guix time-machine in bitcoin#23778, we begun using binutils 2.37 to produce releases. Since then, our windows installer (produced with makensis) has not functioned correctly when run on a Windows system with the "Force randomization for images (Mandatory ASLR)" option enabled. Note that all of our other release binaries, which all contain .reloc sections, function fine under the same option.
fanquake
added a commit
to fanquake/bitcoin
that referenced
this pull request
Aug 5, 2022
With the release of binutils/ld 2.36, ld swapped to much improved default settings when producing windows binaries with mingw-w64. One of these changes was to stop stripping the .reloc section from binaries, which is required for working ASLR. .reloc section stripping is something we've accounted for previously, see bitcoin#18702. The related upstream discussion is in this thread: https://sourceware.org/bugzilla/show_bug.cgi?id=19011. When we switched to using a newer Guix time-machine in bitcoin#23778, we begun using binutils 2.37 to produce releases. Since then, our windows installer (produced with makensis) has not functioned correctly when run on a Windows system with the "Force randomization for images (Mandatory ASLR)" option enabled. Note that all of our other release binaries, which all contain .reloc sections, function fine under the same option, so it cannot be just the presence of a .reloc section that is the issue. For now, restore makensis to it's pre-binutils-2.36 behaviour, which fixes the produced installer. The underlying issue can be further investigated in future.
achow101
added a commit
that referenced
this pull request
Aug 5, 2022
…er stubs 7a0b129 guix: patch NSIS to remove .reloc sections from install stubs (fanquake) Pull request description: With the release of binutils/ld 2.36, ld swapped to much improved default settings when producing windows binaries with mingw-w64. One of these changes was to stop stripping the .reloc section from binaries, which is required for working ASLR. When we switched to using a newer Guix time-machine in #23778, we begun using binutils 2.37 to produce releases. Since then, our windows installer (produced with makensis) has not functioned correctly when run on a Windows system with the "Force randomization for images (Mandatory ASLR)" option enabled. Note that all of our other release binaries, which all contain .reloc sections, function fine under the same option, so it cannot be just the presence of a .reloc section that is the issue. The root cause of the problem is that when we compile NSIS (makensis), a number of exe installer stubs are produced at the same time, for use later when makensis is actually run. Given the new linker defaults, the stubs will contain .reloc sections, when previously they would not. It seems that, in combination with how makensis mutates the stub when it actually builds the installer, causes the problem. According to upstream, https://sourceforge.net/p/nsis/bugs/1131/#abb6: > Looks like the problem is the very existance of the .reloc section. > It's not supposed to be there, and makensis doesn't handle it. The most recent .reloc related upstream activity is in https://sourceforge.net/p/nsis/bugs/1283/, where the conclusion again seemed to be that .relo sections are not wanted, but there hasn't been any further follow up. For now, restore pre-binutils-2.36 behaviour, by passing `-Wl,--disable-reloc-section` to the linker when building the installer stubs, which fixes the produced installer. The underlying issue can be further investigated in future. .reloc section stripping is something we've accounted for previously, see #18702, and related upstream discussion is in this thread: https://sourceware.org/bugzilla/show_bug.cgi?id=19011. Fixes #25726. Guix Build (x86_64): ```bash 7e0723388913ac1ec9f650b943c6b23351ba0cd921c0ec830abf16b16724d503 guix-build-7a0b129c41d9/output/dist-archive/bitcoin-7a0b129c41d9.tar.gz c3bb9c68895ffafa2900b0d18c1268e299d012a7dc70593f20f9900cf116eb05 guix-build-7a0b129c41d9/output/x86_64-w64-mingw32/SHA256SUMS.part b57aa99c242b0aae64653c64ada38f6d3f0cbd902bbc096d3dc529fdcf87d681 guix-build-7a0b129c41d9/output/x86_64-w64-mingw32/bitcoin-7a0b129c41d9-win64-debug.zip 341d99afc9961299883be6cd9666e8bc0f3f6296cff758719a32d27419acad36 guix-build-7a0b129c41d9/output/x86_64-w64-mingw32/bitcoin-7a0b129c41d9-win64-setup-unsigned.exe 1d9ef48d3c9ed93a925962356b41cdaeb9d09fd758de193cd4d5f4d1ec6791eb guix-build-7a0b129c41d9/output/x86_64-w64-mingw32/bitcoin-7a0b129c41d9-win64-unsigned.tar.gz 28c81d99a9a4bd6648449393f91db213369e958add579ba9e9a1721540d2c4f7 guix-build-7a0b129c41d9/output/x86_64-w64-mingw32/bitcoin-7a0b129c41d9-win64.zip ``` Guix Build (arm64): ```bash 7e0723388913ac1ec9f650b943c6b23351ba0cd921c0ec830abf16b16724d503 guix-build-7a0b129c41d9/output/dist-archive/bitcoin-7a0b129c41d9.tar.gz c3bb9c68895ffafa2900b0d18c1268e299d012a7dc70593f20f9900cf116eb05 guix-build-7a0b129c41d9/output/x86_64-w64-mingw32/SHA256SUMS.part b57aa99c242b0aae64653c64ada38f6d3f0cbd902bbc096d3dc529fdcf87d681 guix-build-7a0b129c41d9/output/x86_64-w64-mingw32/bitcoin-7a0b129c41d9-win64-debug.zip 341d99afc9961299883be6cd9666e8bc0f3f6296cff758719a32d27419acad36 guix-build-7a0b129c41d9/output/x86_64-w64-mingw32/bitcoin-7a0b129c41d9-win64-setup-unsigned.exe 1d9ef48d3c9ed93a925962356b41cdaeb9d09fd758de193cd4d5f4d1ec6791eb guix-build-7a0b129c41d9/output/x86_64-w64-mingw32/bitcoin-7a0b129c41d9-win64-unsigned.tar.gz 28c81d99a9a4bd6648449393f91db213369e958add579ba9e9a1721540d2c4f7 guix-build-7a0b129c41d9/output/x86_64-w64-mingw32/bitcoin-7a0b129c41d9-win64.zip ``` ACKs for top commit: achow101: ACK 7a0b129 hebasto: ACK 7a0b129 jarolrod: ACK 7a0b129 Tree-SHA512: 9e14e98207d20236b833603319fc4bb335c878a7c179ab495b33d143e2a900c6926125536bbb7499ee4f0f676cd5ea45c8c86cd7e544ed9a76bb298f98db6197
sidhujag
pushed a commit
to syscoin/syscoin
that referenced
this pull request
Aug 6, 2022
…installer stubs 7a0b129 guix: patch NSIS to remove .reloc sections from install stubs (fanquake) Pull request description: With the release of binutils/ld 2.36, ld swapped to much improved default settings when producing windows binaries with mingw-w64. One of these changes was to stop stripping the .reloc section from binaries, which is required for working ASLR. When we switched to using a newer Guix time-machine in bitcoin#23778, we begun using binutils 2.37 to produce releases. Since then, our windows installer (produced with makensis) has not functioned correctly when run on a Windows system with the "Force randomization for images (Mandatory ASLR)" option enabled. Note that all of our other release binaries, which all contain .reloc sections, function fine under the same option, so it cannot be just the presence of a .reloc section that is the issue. The root cause of the problem is that when we compile NSIS (makensis), a number of exe installer stubs are produced at the same time, for use later when makensis is actually run. Given the new linker defaults, the stubs will contain .reloc sections, when previously they would not. It seems that, in combination with how makensis mutates the stub when it actually builds the installer, causes the problem. According to upstream, https://sourceforge.net/p/nsis/bugs/1131/#abb6: > Looks like the problem is the very existance of the .reloc section. > It's not supposed to be there, and makensis doesn't handle it. The most recent .reloc related upstream activity is in https://sourceforge.net/p/nsis/bugs/1283/, where the conclusion again seemed to be that .relo sections are not wanted, but there hasn't been any further follow up. For now, restore pre-binutils-2.36 behaviour, by passing `-Wl,--disable-reloc-section` to the linker when building the installer stubs, which fixes the produced installer. The underlying issue can be further investigated in future. .reloc section stripping is something we've accounted for previously, see bitcoin#18702, and related upstream discussion is in this thread: https://sourceware.org/bugzilla/show_bug.cgi?id=19011. Fixes bitcoin#25726. Guix Build (x86_64): ```bash 7e0723388913ac1ec9f650b943c6b23351ba0cd921c0ec830abf16b16724d503 guix-build-7a0b129c41d9/output/dist-archive/bitcoin-7a0b129c41d9.tar.gz c3bb9c68895ffafa2900b0d18c1268e299d012a7dc70593f20f9900cf116eb05 guix-build-7a0b129c41d9/output/x86_64-w64-mingw32/SHA256SUMS.part b57aa99c242b0aae64653c64ada38f6d3f0cbd902bbc096d3dc529fdcf87d681 guix-build-7a0b129c41d9/output/x86_64-w64-mingw32/bitcoin-7a0b129c41d9-win64-debug.zip 341d99afc9961299883be6cd9666e8bc0f3f6296cff758719a32d27419acad36 guix-build-7a0b129c41d9/output/x86_64-w64-mingw32/bitcoin-7a0b129c41d9-win64-setup-unsigned.exe 1d9ef48d3c9ed93a925962356b41cdaeb9d09fd758de193cd4d5f4d1ec6791eb guix-build-7a0b129c41d9/output/x86_64-w64-mingw32/bitcoin-7a0b129c41d9-win64-unsigned.tar.gz 28c81d99a9a4bd6648449393f91db213369e958add579ba9e9a1721540d2c4f7 guix-build-7a0b129c41d9/output/x86_64-w64-mingw32/bitcoin-7a0b129c41d9-win64.zip ``` Guix Build (arm64): ```bash 7e0723388913ac1ec9f650b943c6b23351ba0cd921c0ec830abf16b16724d503 guix-build-7a0b129c41d9/output/dist-archive/bitcoin-7a0b129c41d9.tar.gz c3bb9c68895ffafa2900b0d18c1268e299d012a7dc70593f20f9900cf116eb05 guix-build-7a0b129c41d9/output/x86_64-w64-mingw32/SHA256SUMS.part b57aa99c242b0aae64653c64ada38f6d3f0cbd902bbc096d3dc529fdcf87d681 guix-build-7a0b129c41d9/output/x86_64-w64-mingw32/bitcoin-7a0b129c41d9-win64-debug.zip 341d99afc9961299883be6cd9666e8bc0f3f6296cff758719a32d27419acad36 guix-build-7a0b129c41d9/output/x86_64-w64-mingw32/bitcoin-7a0b129c41d9-win64-setup-unsigned.exe 1d9ef48d3c9ed93a925962356b41cdaeb9d09fd758de193cd4d5f4d1ec6791eb guix-build-7a0b129c41d9/output/x86_64-w64-mingw32/bitcoin-7a0b129c41d9-win64-unsigned.tar.gz 28c81d99a9a4bd6648449393f91db213369e958add579ba9e9a1721540d2c4f7 guix-build-7a0b129c41d9/output/x86_64-w64-mingw32/bitcoin-7a0b129c41d9-win64.zip ``` ACKs for top commit: achow101: ACK 7a0b129 hebasto: ACK 7a0b129 jarolrod: ACK 7a0b129 Tree-SHA512: 9e14e98207d20236b833603319fc4bb335c878a7c179ab495b33d143e2a900c6926125536bbb7499ee4f0f676cd5ea45c8c86cd7e544ed9a76bb298f98db6197
fanquake
added a commit
to fanquake/bitcoin
that referenced
this pull request
Aug 7, 2022
With the release of binutils/ld 2.36, ld swapped to much improved default settings when producing windows binaries with mingw-w64. One of these changes was to stop stripping the .reloc section from binaries, which is required for working ASLR. .reloc section stripping is something we've accounted for previously, see bitcoin#18702. The related upstream discussion is in this thread: https://sourceware.org/bugzilla/show_bug.cgi?id=19011. When we switched to using a newer Guix time-machine in bitcoin#23778, we begun using binutils 2.37 to produce releases. Since then, our windows installer (produced with makensis) has not functioned correctly when run on a Windows system with the "Force randomization for images (Mandatory ASLR)" option enabled. Note that all of our other release binaries, which all contain .reloc sections, function fine under the same option, so it cannot be just the presence of a .reloc section that is the issue. For now, restore makensis to it's pre-binutils-2.36 behaviour, which fixes the produced installer. The underlying issue can be further investigated in future. Github-Pull: bitcoin#25788 Rebased-From: 7a0b129
Rspigler
pushed a commit
to Rspigler/bitcoin
that referenced
this pull request
Aug 21, 2022
With the release of binutils/ld 2.36, ld swapped to much improved default settings when producing windows binaries with mingw-w64. One of these changes was to stop stripping the .reloc section from binaries, which is required for working ASLR. .reloc section stripping is something we've accounted for previously, see bitcoin#18702. The related upstream discussion is in this thread: https://sourceware.org/bugzilla/show_bug.cgi?id=19011. When we switched to using a newer Guix time-machine in bitcoin#23778, we begun using binutils 2.37 to produce releases. Since then, our windows installer (produced with makensis) has not functioned correctly when run on a Windows system with the "Force randomization for images (Mandatory ASLR)" option enabled. Note that all of our other release binaries, which all contain .reloc sections, function fine under the same option, so it cannot be just the presence of a .reloc section that is the issue. For now, restore makensis to it's pre-binutils-2.36 behaviour, which fixes the produced installer. The underlying issue can be further investigated in future.
dekm
pushed a commit
to unigrid-project/daemon
that referenced
this pull request
Oct 27, 2022
With the release of binutils/ld 2.36, ld swapped to much improved default settings when producing windows binaries with mingw-w64. One of these changes was to stop stripping the .reloc section from binaries, which is required for working ASLR. .reloc section stripping is something we've accounted for previously, see bitcoin#18702. The related upstream discussion is in this thread: https://sourceware.org/bugzilla/show_bug.cgi?id=19011. When we switched to using a newer Guix time-machine in bitcoin#23778, we begun using binutils 2.37 to produce releases. Since then, our windows installer (produced with makensis) has not functioned correctly when run on a Windows system with the "Force randomization for images (Mandatory ASLR)" option enabled. Note that all of our other release binaries, which all contain .reloc sections, function fine under the same option, so it cannot be just the presence of a .reloc section that is the issue. For now, restore makensis to it's pre-binutils-2.36 behaviour, which fixes the produced installer. The underlying issue can be further investigated in future.
dekm
added a commit
to unigrid-project/daemon
that referenced
this pull request
Nov 7, 2022
* guix: Add guix-verify script
* guix-attest: Only use cross-platform flags for find+xargs
* guix-attest: Use ascii-armor signatures
* guix-attest: Allow skipping GPG signing with NO_SIGN
* guix: Minor quoting fix in libexec/build.sh
* guix: Construct $OUTDIR in ${DISTSRC}/output
While files are being output to $OUTDIR, it will be under
${DISTSRC}/output, and only when everything is done, will
${DISTSRC}/output be moved to the actual $OUTDIR.
This makes it so that a Ctrl-C in the middle of a build is less likely
to result in a partially-constructed $OUTDIR. In fact, if I understand
correctly, if $OUTDIR and $DISTSRC reside on the same filesystem, the
move (rename) is likely atomic.
Also, since the "working $OUTDIR" is under ${DISTSRC}/output, it will be
cleaned properly by the guix-clean script.
* guix: Attest to inputs in inputs.SHA256SUMS
At build/codesigning-time, hash build inputs and output the digest to
${OUTDIR}/inputs.SHA256SUMS, which gets included in the final SHA256SUMS
constructed by guix-attest.
Example final SHA256SUMS:
ee832d2a35b7701bff581dea05a536118b118e3ad0a587a2855b6ee8cd6fba20 inputs/bitcoin-78199266af7b.tar.gz
ca765e70a0c12866dd63c0be228b675278a26329e5f8f5b5c52fd09200fedf21 bitcoin-78199266af7b-powerpc64le-linux-gnu-debug.tar.gz
dae95327d7f2c324e2728c4b73627be6cb2c0d2f2e5bea940d1d5e6463939327 bitcoin-78199266af7b-powerpc64le-linux-gnu.tar.gz
* guix: Skip attesting to dist-archive
We already attest to the relevant dist-archive in inputs.SHA256SUMS,
which is recorded at build-time.
We use a SKIPATTEST.TAG file to indicate output directories which do not
require attestation (much like the CACHEDIR.TAG specification).
Generally, it's better to have build scripts declare properties of
directories instead of introducing name-based special cases in attest
scripts since build scripts have a more detailed context of what is
going on.
* guix: Consistently use gcc-8 for $HOST
* guix-attest: Avoid incomplete sigdirs with ERR traps
Sometimes GPG connects to the wrong agent... or you don't have your
smartcard handy...
* guix: install LIEF in Guix container
Co-authored-by: Carl Dong <contact@carldong.me>
* build: Makes rcc output always deterministic
The Qt Resource Compiler (rcc) has a command-line option
`--format-version` which has the default value 2.
The only difference from `--format-version 1` is adding a last modified
timestamp to the output file. That, in turn, forces us to use
`QT_RCC_SOURCE_DATE_OVERRIDE=1` to get deterministic builds.
This change makes rcc output always deterministic by using
`--format-version 1` option that makes usage of the
`QT_RCC_SOURCE_DATE_OVERRIDE` needless. Also it improves interaction
with ccache.
Co-authored-by: fanquake <fanquake@gmail.com>
* guix: Reindent existing manifest.scm
* guix: Package codesigning tools
* guix: Add codesigning functionality
* guix: repro: Sort find output in libtool for gcc-8
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
* guix: Remove dest if OUTDIR mv fails
* guix: Check for disk space availability before building
* Use latest signapple commit
Update gitian and guix to use the same latest signapple commit
* Make SHA256SUMS fragment right after build
* Rewrite guix-{attest,verify} for new hier
* scripts: LIEF 0.11.5
* guix-attest: Error out if SHA256SUMS is unexpected
* guix: Rebase toolchain on glibc 2.24 (2.27 for riscv64)
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.
* guix: Build depends/qt with our platform definition
Our 'bitcoin-linux-g++' definition better integrates with our depends
system than the stock linux-g++-64 definition.
This fixes a bug whereby Guix builds on x86_64 for x86_64 did not
produce a QMinimalIntegrationPlugin and led to bitcoin-qt not being
built.
* guix: Also sort SHA256SUMS.part
* guix: no-longer pass --enable-glibc-back-compat to Guix
Now that our Guix builds are performed on glibc 2.24 and 2.27 (RISCV),
we no-longer need to pass the --enable-glibc-back-compat option.
Replace it with --disable-threadlocal, to prevent the usage of symbols
from glibc 2.18.
None of the binaries produced required symbols later than 2.17, and 2.27
(RISCV).
* guix: add additional documentation to patches
* Avoid GCC 7.1 ABI change warning in guix build
* guix: Patch binutils to add security-related disable flags
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.
* guix: Test security-check sanity before performing them
* guix: Check for a sane services database
On bare systems, it is possible to be lacking a services database. Check
for basic entries before attempting a build.
See the error message in the diff for more context.
* guix: Update various check_tools lists
* guix: Pin kernel header version
- Use 4.19 for riscv64 (earliest LTS release w/ riscv64 support)
- Use 4.9 for all others (second-oldest LTS release, released in
combination with glibc glibc 2.24 in Debian stretch)
* guix: Bump to version-1.3.0 from upstream
The chosen commit is the HEAD of Guix's version-1.3.0 branch as of July
15th, 2021.
Also fix visual indenting.
* guix: Overhaul README
- Added detailed Guix bootstrap/installation instructions
* guix-attest: Produce and sign normalized documents
That way we can easily combine the document and detached signature to
produce cleartext signature files for upload during the release process.
See subsequent commits which modify doc/release-process.md for more
details.
* guix/INSTALL: Add coreutils/inotify-dir-recreate troubleshooting
* guix/INSTALL: Guix installs init scripts in libdir
* guix: Silence getent(1) invocation
* guix/INSTALL: Misc fixups
* guix/build: Remove vestigial SKIPATTEST.TAG
* guix: Make all.SHA256SUMS rather than codesigned.SHA256SUMS
* guix: Allow changing the base manifest in guix-verify
When verifying guix attestations, it is useful to set a particular
signer's manifest as the base to compare against.
* Updated Readme, Corrected the codesign typo
* script, doc: guix touchups
* guix: Remove extra \r from all.SHA256SUMS line ending
guix-attest mistakenly added an extra \r to the line endings in
all.SHA256SUMS, causing guix-verify to erroneously fail.
Co-Authored-By: Carl Dong <contact@carldong.me>
* guix: Ensure EPOCH_SOURCE_DATE does not include GPG information
If the user has set log.showSignature=true in their git config, then the
git log will always output GPG signature information. Since git log is
used to set EPOCH_SOURCE_DATE, this will mistakenly have GPG signature
information in it which causes issues for the build. To avoid this
issue, we override the config and force log.showSignature=false.
* release: Release with separate SHA256SUMS and sig files
This allows us to remove the rfc4880 EOL hacks and release with a
SHA256SUMS.asc file that's a combination of all signer signatures.
* guix-verify: Non-zero exit code when anything fails
Previously, if verification fails, the correct message will be printed,
but the exit code would still be 0.
* guix: Don't include directory name in SHA256SUMS
The SHA256SUMS file can be used in a sha256sum -c command to verify
downloaded binaries. However users are likely to download just a single
file and not place this file in the correct directory relative to the
SHA256SUMS file for the simple verification command to work. By not
including the directory name in the SHA256SUMS file, it will be easier
for users to verify downloaded binaries.
Co-authored-by: Carl Dong <contact@carldong.me>
* guix/prelude: Override VERSION with FORCE_VERSION
Previously, if the builder exported $VERSION in their environment (as
past Gitian-building docs told them to), but their HEAD does not
actually point to v$VERSION, their build outputs will differ from those
of other builders.
This is because the contrib/guix/guix-* scripts only ever act on the
current git worktree, and does not try to check out $VERSION if $VERSION
is set in the environment.
Setting $VERSION only makes the scripts pretend like the current
worktree is $VERSION.
This problem was seen in jonatack's attestation for all.SHA256SUMS,
where only his bitcoin-22.0rc3-osx-signed.dmg differed from everyone
else's.
Here is my deduced sequence of events:
1. Aug 27th: He guix-builds 22.0rc3 and uploads his attestations up to
guix.sigs
2. Aug 30th, sometime after POSIX time 1630310848: he pulls the latest
changes from master in the same worktree where he guix-built 22.0rc3
and ends up at 7be143a
3. Aug 30th, sometime before POSIX time 1630315907: With his worktree
still on 7be143a, he guix-codesigns. Normally, this would result
in outputs going in guix-build-7be143a960e2, but he had
VERSION=22.0rc3 in his environment, so the guix-* scripts pretended
like he was building 22.0rc3, and used 22.0rc3's guix-build directory
to locate un-codesigned outputs and dump codesigned ones.
However, our SOURCE_DATE_EPOCH defaults to the POSIX time of HEAD
(7be143a), which made all timestamps in the resulting codesigned
DMG 1630310848, 7be143a's POSIX timestamp. This differs from the
POSIX timestamp of 22.0rc3, which is 1630348517. Note that the
windows codesigning procedure does not consider SOURCE_DATE_EPOCH.
We resolve this by only allowing VERSION overrides via the FORCE_VERSION
environment variable.
* build: set OSX_MIN_VERSION to 10.15
This is required to use std::filesystem on macOS as support for it only
landed in the libc++ dylib shipped with 10.15.
See also: https://developer.apple.com/documentation/xcode-release-notes/xcode-11-release-notes
Clang now supports the C++17 <filesystem> library for iOS 13, macOS 10.15, watchOS 6, and tvOS 13.
* Enable TLS in links in documentation
* Integrate univalue into our buildsystem
This addresses issues like the one in bitcoin#12467, where some of our compiler flags
end up being dropped during the subconfigure of Univalue. Specifically, we're
still using the compiler-default c++ version rather than forcing c++17.
We can drop the need subconfigure completely in favor of a tighter build
integration, where the sources are listed separately from the build recipes,
so that they may be included directly by upstream projects. This is
similar to the way leveldb build integration works in Core.
Core benefits of this approach include:
- Better caching (for ex. ccache and autoconf)
- No need for a slow subconfigure
- Faster autoconf
- No more missing compile flags
- Compile only the objects needed
There are no benefits to Univalue itself that I can think of. These changes
should be a no-op there, and to downstreams as well until they take advantage
of the new sources.mk.
This also removes the option to use an external univalue to avoid similar ABI
issues with mystery binaries.
Co-authored-by: fanquake <fanquake@gmail.com>
* guix: Fix powerpc64(le) dynamic linker name
I used Guix's values for the powerpc64(le) dynamic linkers, and the
/lib-prefix seems to be a Guix-ism rather than standard. The standard
path for the linker-loaders start with /lib64.
I've taken the new loader values from SYSDEP_KNOWN_INTERPRETER_NAMES in
glibc's sysdeps/unix/sysv/linux/powerpc/ldconfig.h file.
For future reference, loader path values can also be found on glibc's
website: https://sourceware.org/glibc/wiki/ABIList?action=recall&rev=16
* build: require glibc 2.18+ for release builds
From what I can see the only platform this drops support for is CentOS
7. CentOS 7 reached the end of it's "full update" support at the end of
2020. It does receive maintenance updates until 2024, however I don't
think supporting glibc 2.17 until 2024 is realistic. Note that anyone
wanting to self-compile and target a glibc 2.17 runtime could build with
--disable-threadlocal.
glibc 2.18 was released in August 2013.
https://sourceware.org/legacy-ml/libc-alpha/2013-08/msg00160.html
* scripted-diff: Drop Darwin version for better maintainability
-BEGIN VERIFY SCRIPT-
sed -i 's/darwin19/darwin/g' $(git grep --files-with-matches 'darwin19')
-END VERIFY SCRIPT-
* test: Make more shell scripts verifiable by the `shellcheck` tool
* test: Bump shellcheck version to 0.8.0
* scripted-diff: Insert missed copyright headers
-BEGIN VERIFY SCRIPT-
./contrib/devtools/copyright_header.py insert contrib/guix/libexec/build.sh
./contrib/devtools/copyright_header.py insert contrib/guix/libexec/codesign.sh
./contrib/devtools/copyright_header.py insert contrib/tracing/log_raw_p2p_msgs.py
./contrib/devtools/copyright_header.py insert contrib/tracing/log_utxocache_flush.py
./contrib/devtools/copyright_header.py insert contrib/tracing/p2p_monitor.py
./contrib/devtools/copyright_header.py insert test/lint/lint-files.sh
-END VERIFY SCRIPT-
* build: use a static .tiff for macOS .dmg over generating
Co-authored-by: Pavol Rusnak <pavol@rusnak.io>
* guix: use GCC 10 (over GCC 8) to build releases
This currently points to the version-1.4.0 branch.
* guix: use uptream nsis-x86_64
Our patch is now used upstream.
* build: use python-asn1crypto from upstream
It is the exact same package definition.
* guix: use upstream python-requests (2.26.0)
Upstream python requests is now modern enough to be used as a dependency for
signapple. Which requires requests>=2.25.1.
* build: Point Guix to the current top of the "version-1.4.0" branch
* build: point to latest commit on the master branch
The version-1.4.0 branch no-longer exists, and will be branched off
master again shortly.
* guix: ignore additioanl failing certvalidator test
======================================================================
ERROR: test_revocation_mode_soft (tests.test_validate.ValidateTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/tmp/guix-build-python-certvalidator-0.1-1.e5bdb4b.drv-0/source/tests/test_validate.py", line 85, in test_revocation_mode_soft
validate_path(context, path)
File "/tmp/guix-build-python-certvalidator-0.1-1.e5bdb4b.drv-0/source/tests/../certvalidator/validate.py", line 50, in validate_path
return _validate_path(validation_context, path)
File "/tmp/guix-build-python-certvalidator-0.1-1.e5bdb4b.drv-0/source/tests/../certvalidator/validate.py", line 358, in _validate_path
raise PathValidationError(pretty_message(
certvalidator.errors.PathValidationError: The path could not be validated because the end-entity certificate expired 2022-01-14 12:00:00Z
* build: Fix xargs warnings for Guix builds
* build: use macOS 11 SDK (Xcode 12.2)
This should be sufficient to support building for Apple ARM when
cross-compiling.
* guix: use autoconf 2.71
This allows for building with newer targets, like arm64-apple-darwin, due to
having a newer bundled config.guess and config.sub.
* guix: add arm64-apple-darwin triplet
* build: Fix gcc-cross-x86_64-w64-mingw32-10.3.0 in Guix
* build: Point Guix to recent commit on the master branch
* Replace "can not" with "cannot" in docs, user messages, and tests
* guix: use same commit for codesigning time-machine
The time machines should be updated in lockstep.
* build: Move guix time machine to prelude
This deduplicates some code, and enforces consistency of the time
machine configuration between scripts.
* guix: only use native GCC 7 toolchain for Linux builds
The macOS and Windows builds do not require a GCC 7 toolchain, and this
is actually causing build issues, i.e bitcoin#24211. So switch to using a GCC
10 native toolchain for both.
* guix: use latest upstream python-certvalidator
This should also allow re-enabling previously failing tests.
* guix: use latest upstream signapple
This should improve support for signing for M1 binaries.
* guix: Drop unneeded openssl dependency for signapple
* guix: use latest signapple
* guix: only check for the macOS SDK once
If we are building for both macOS HOSTS, there's no need to check and
print that the SDK exists two times.
* guix: Use $HOST instead of generic osx{64} for macOS artifacts
* guix: make it possible to override gpg binary
For example on Qubes OS one might want to use qubes-gpg-client-wrapper instead
* guix: Drop "-signed" suffix for signed macOS .dmg files
This change makes naming of the signed artifacts consistent across
different OSes, including Windows.
* guix: Use "win64" for Windows artifacts consistently
* Update signapple for platform identifier fix
* doc, guix: Include arm64-apple-darwin into codesigned archs
* guix: point to latest upstream commit
* Revert "build: Fix gcc-cross-x86_64-w64-mingw32-10.3.0 in Guix"
This reverts commit 7f2f35f.
* macdeploy: remove unused detached-sig-apply
Signature application is now done with signapple.
* guix: Drop code for the unsupported `i686-linux-gnu` host
Now GUIX build for the `i686-linux-gnu` host is broken, and there are no
plans to re-add it.
* contrib: use LIEF 0.12.0 for symbol and security checks
* build: Fix "ERR: Unsigned tarballs do not exist"
* guix: fix vmov alignment issues with gcc 10.3.0 & mingw-w64
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 bitcoin#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 bitcoin#24726.
Alternative to bitcoin#24727.
See also:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939559
* build: don't compress macOS DMG
* guix: fix GCC 10.3.0 + mingw-w64 setjmp/longjmp issues
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: bitcoin-core/gui#582.
See also:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=e8d1ca7d2c344a411779892616c423e157f4aea8.
https://bugreports.qt.io/browse/QTBUG-93476.
* guix: Improve error message about missed macOS SDK
* guix: consolidate kernel headers to 5.15
Given no reason to use an older version of the kernel headers for the
non-RISCV linux builds, consolidate all Linux builds to 5.15.x.
Note that using older kernel headers isn't some sort of compatibility
"hack", and glibc explicitly recommends against doing so. See:
https://sourceware.org/glibc/wiki/FAQ#What_version_of_the_Linux_kernel_headers_should_be_used.3F.
* build: include bitcoin.conf in build outputs
copy over bitcoin.conf during the build process.
this means `contrib/devtools/gen-bitcoin-conf.sh` will need
to be run and the generated file committed during the release process.
this is the same process used for generating man pages for each release.
* guix: bump time-machine to 998eda3067c7d21e0d9bb3310d2f5a14b8f1c681
There are two reasons to perform this bump:
* Fixes bitcoin#25082 by bumping to a commit that includes a fix for time-dependent unit
tests in libgit2 (f5fe0082abe4547f3fb9f29d8351473cfb3a387b).
* Gives us access to clang-toolchain-14 (14.0.3, 998eda3067c7d21e0d9bb3310d2f5a14b8f1c681),
which is useful for the Guix portion of bitcoin#21778.
Note that with this bump:
Linux kernels headers update from 5.15.28 to 5.15.37.
* guix: compile glibc without -werror
Compiling glibc 2.24 and 2.27 with the new GCC 10 results in a number of new warnings,
i.e:
```bash
libc-tls.c: In function ‘__libc_setup_tls’:
libc-tls.c:208:30: error: array subscript 1 is outside the bounds of an interior zero-length array ‘struct dtv_slotinfo[0]’ [-Werror=zero-length-bounds]
208 | static_slotinfo.si.slotinfo[1].map = main_map;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~
In file included from ../sysdeps/x86_64/ldsodefs.h:54,
from ../sysdeps/gnu/ldsodefs.h:46,
from ../sysdeps/unix/sysv/linux/ldsodefs.h:25,
from libc-tls.c:20:
../sysdeps/generic/ldsodefs.h:398:7: note: while referencing ‘slotinfo’
398 | } slotinfo[0];
| ^~~~~~~~
```
While we could try and backport all the patches required to fix these up, it would
currently seem easier to disable -Werror, which Guix uses by default when building
glibc.
* guix: adjust RISC-V __has_include() patch to work with GCC 10
The actual macro is __has_include(), not __has_include__(), using the
later would result in build failures when using GCC 10. i.e:
```bash
../sysdeps/unix/sysv/linux/riscv/flush-icache.c:24:5: warning: "__has_include__" is not defined, evaluates to 0 [-Wundef]
24 | #if __has_include__ (<asm/syscalls.h>)
```
Looks like at least someone else has run into the same thing, see:
http://lists.busybox.net/pipermail/buildroot/2020-July/590376.html.
See also:
https://gcc.gnu.org/onlinedocs/cpp/_005f_005fhas_005finclude.html
https://clang.llvm.org/docs/LanguageExtensions.html#has-include
* guix: fix glibc 2.27 multiple definition warnings with GCC 10
* guix: use -fcommon when building glibc 2.24
GCC 10 started using -fno-common by default, which causes issues with
the powerpc builds using gibc 2.24. A patch was commited to glibc to fix
the issue, 18363b4f010da9ba459b13310b113ac0647c2fcc but is non-trvial
to backport, and was broken in at least one way, see the followup in
commit 7650321ce037302bfc2f026aa19e0213b8d02fe6.
For now, retain the legacy GCC behaviour by passing -fcommon when
building glibc 2.24.
https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html.
https://sourceware.org/git/?p=glibc.git;a=commit;h=18363b4f010da9ba459b13310b113ac0647c2fcc
https://sourceware.org/git/?p=glibc.git;a=commit;h=7650321ce037302bfc2f026aa19e0213b8d02fe6
* guix: native GCC 10 toolchain for Linux builds
* guix: re-revert riscv execstack workaround
Now that we use GCC 10 for release builds, we no-longer need to
pass-Wl,-z,noexecstack to get a non-executable stack in RISC-V binaries.
This was originally removed in bitcoin#21036, but then re-added in bitcoin#21799, when
we reverted to using GCC 8.
* guix: use libtool 2.4.7
As of version 2.4.7, libtool now respects ARFLAGS, which we use, and has
changed the default ARFLAGS from cru to cr (which we also do, see
configure).
This eliminates spammy `ar` output such as:
```bash
CXXLD libunivalue.la
/root/.guix-profile/bin/x86_64-linux-gnu-ar: `u' modifier ignored since `D' is the default (see `U')
AR libbitcoin_zmq.a
AR libbitcoin_consensus.a
CXXLD crypto/libbitcoin_crypto_base.la
CXXLD crypto/libbitcoin_crypto_sse41.la
/root/.guix-profile/bin/x86_64-linux-gnu-ar: `u' modifier ignored since `D' is the default (see `U')
/root/.guix-profile/bin/x86_64-linux-gnu-ar: `u' modifier ignored since `D' is the default (see `U')
CXXLD crypto/libbitcoin_crypto_avx2.la
CXXLD crypto/libbitcoin_crypto_x86_shani.la
CXXLD leveldb/libleveldb.la
/root/.guix-profile/bin/x86_64-linux-gnu-ar: `u' modifier ignored since `D' is the default (see `U')
CXXLD crc32c/libcrc32c.la
/root/.guix-profile/bin/x86_64-linux-gnu-ar: `u' modifier ignored since `D' is the default (see `U')
CXXLD leveldb/libmemenv.la
/root/.guix-profile/bin/x86_64-linux-gnu-ar: `u' modifier ignored since `D' is the default (see `U')
/root/.guix-profile/bin/x86_64-linux-gnu-ar: `u' modifier ignored since `D' is the default (see `U')
/root/.guix-profile/bin/x86_64-linux-gnu-ar: `u' modifier ignored since `D' is the default (see `U')
AR libbitcoin_cli.a
```
Libtool 2.4.7 release notes:
https://lists.gnu.org/archive/html/autotools-announce/2022-03/msg00000.html
* guix: remove explicit glibc stack protector disabling
While glibc 2.25 and newer *can* be built with stack-smashing-protection
enabled, it isn't used by default, and still isn't, as of glibc 2.35,
so I can't see a reason to explicitly disable it.
I'd also like to move in the direction of enabling, by default,
hardening options for the toolchains we build, so removing the explicit
disabling is a step in that direction.
Will be following up with some changes based on this PR.
* guix: parallelize LIEF build
* guix: remove usage of -Wl,-z,noexecstack for PPC64 HOST
The PPC64 ABI has a non-executable stack by default, and does not need a
GNU_STACK program header.
See also:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/include/asm/page_64.h#n92
* guix: use LIEF 0.12.1
* guix: patch LIEF to fix PPC64 NX default
This patches our LIEF build using the change merged upstream:
lief-project/LIEF#718.
This can be dropped the next time we update LIEF.
* guix: Map all guix store prefixes to /usr
Without ffile-prefix-map, the debug symbols will contain paths for the
guix store which will include the hashes of each package. However, the
hash for the same package will differ when on different architectures.
In order to be reproducible regardless of the architecture used to build
the package, map all guix store prefixes to something fixed, e.g. /usr.
* guix: Remove guix store paths from glibc
Without ffile-prefix-map, the debug symbols will contain paths for the
guix store which will include the hashes of each package. However, the
hash for the same package will differ when on different architectures.
In order to be reproducible regardless of the architecture used to build
the package, map all guix store prefixes to something fixed, e.g. /usr.
We might be able to drop this in favour of using --with-nonshared-cflags
when we being using newer versions of glibc.
* guix: use elfesteem 2eb1e5384ff7a220fd1afacd4a0170acff54fe56
Our patch has been merged upstream, see
LRGH/elfesteem#3
* guix: patch gcc 10 with pthreads to remap guix store paths
* guix: Drop repetition of option's default value
* guix: enable SSP for RISC-V glibc (2.27)
Pass `--enable-stack-protector=all` when building the glibc used for the
RISC-V toolchain, to enable stack smashing protection on all functions,
in the glibc code.
* guix: pass enable-bind-now to glibc
Both glibcs we build support `--enable-bind-now`:
Disable lazy binding for installed shared objects and programs.
This provides additional security hardening because it enables full RELRO
and a read-only global offset table (GOT), at the cost of slightly
increased program load times.
See:
https://www.gnu.org/software/libc/manual/html_node/Configuring-and-compiling.html
* guix: enable hardening options in GCC Build
Pass `--enable-default-pie` and `--enable-default-ssp` when configuring
our GCCs. This achieves the following:
--enable-default-pie
Turn on -fPIE and -pie by default.
--enable-default-ssp
Turn on -fstack-protector-strong by default.
Note that this isn't a replacement for passing hardneing flags
ourselves, but introduces some redundency, and there isn't really a
reason to not build a more "hardenings enabled" toolchain by default.
See also:
https://gcc.gnu.org/install/configure.html
* guix: ignore additional failing certvalidator test
Similar to 8588591.
```bash
ERROR: test_revocation_mode_soft (tests.test_validate.ValidateTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/tmp/guix-build-python-certvalidator-0.1-1.a145bf2.drv-0/source/tests/test_validate.py", line 85, in test_revocation_mode_soft
validate_path(context, path)
File "/tmp/guix-build-python-certvalidator-0.1-1.a145bf2.drv-0/source/tests/../certvalidator/validate.py", line 50, in validate_path
return _validate_path(validation_context, path)
File "/tmp/guix-build-python-certvalidator-0.1-1.a145bf2.drv-0/source/tests/../certvalidator/validate.py", line 358, in _validate_path
raise PathValidationError(pretty_message(
certvalidator.errors.PathValidationError: The path could not be validated because the end-entity certificate expired 2022-07-27 12:00:00Z
```
* guix: patch NSIS to remove .reloc sections from install stubs
With the release of binutils/ld 2.36, ld swapped to much improved
default settings when producing windows binaries with mingw-w64. One of
these changes was to stop stripping the .reloc section from binaries,
which is required for working ASLR.
.reloc section stripping is something we've accounted for previously,
see bitcoin#18702. The related upstream discussion is in this thread:
https://sourceware.org/bugzilla/show_bug.cgi?id=19011.
When we switched to using a newer Guix time-machine in bitcoin#23778, we begun
using binutils 2.37 to produce releases. Since then, our windows
installer (produced with makensis) has not functioned correctly when run on
a Windows system with the "Force randomization for images (Mandatory ASLR)"
option enabled. Note that all of our other release binaries, which all
contain .reloc sections, function fine under the same option, so it
cannot be just the presence of a .reloc section that is the issue.
For now, restore makensis to it's pre-binutils-2.36 behaviour, which
fixes the produced installer. The underlying issue can be further
investigated in future.
* doc: minor updates to guix README
* build: include share/rpcauth in tarball & installer
Fixes bitcoin#19081.
* guix: use --build={arch}-guix-linux-gnu in cross toolchain
Technically we are always cross-compiling, so make that explicit.
Fixes: bitcoin#22458.
* guix: consistently use -ffile-prefix-map
Aside from being the newer, more comprehensive option, it's what we
claim to use in the patch docs, and everywhere else in guix.
* guix: use git-minimal over git
From the git-minimal package definition:
> The size of the closure of 'git-minimal' is two thirds that of 'git'.
> Its test suite runs slightly faster and most importantly it doesn't
> depend on packages that are expensive to build such as Subversion.
We don't need any fancy / additional git functionality above the basics,
so switch to git-minimal and save some CPU, while also pruning the
greater dependency graph.
```diff
-name: git
+name: git-minimal
version: 2.37.3
outputs:
-+ send-email: see Appendix H
-+ svn: see Appendix H
-+ credential-netrc: see Appendix H
-+ credential-libsecret: see Appendix H
-+ subtree: see Appendix H
-+ gui: see Appendix H
+ out: everything else
-systems: x86_64-linux mips64el-linux aarch64-linux powerpc64le-linux i686-linux armhf-linux powerpc-linux
-dependencies: asciidoc@9.1.0 bash-minimal@5.1.8 bash@5.1.8 curl@7.79.1 docbook-xsl@1.79.2 expat@2.4.1 gettext-minimal@0.21 glib@2.70.2 libsecret@0.20.4 openssl@1.1.1l pcre2@10.37 perl-authen-sasl@2.16 perl-cgi@4.52
-+ perl-io-socket-ssl@2.068 perl-net-smtp-ssl@1.04 perl-term-readkey@2.38 perl@5.34.0 pkg-config@0.29.2 python@3.9.9 subversion@1.14.1 tcl@8.6.11 tk@8.6.11.1 xmlto@0.0.28 zlib@1.2.11
-location: gnu/packages/version-control.scm:222:2
+systems: x86_64-linux mips64el-linux aarch64-linux powerpc64le-linux riscv64-linux i686-linux armhf-linux powerpc-linux
+dependencies: bash-minimal@5.1.8 bash@5.1.8 curl@7.79.1 expat@2.4.1 gettext-minimal@0.21 openssl@1.1.1l perl@5.34.0 zlib@1.2.11
+location: gnu/packages/version-control.scm:608:2
homepage: https://git-scm.com/
license: GPL 2
synopsis: Distributed version control system
```
* guix: Drop perl package
* Revert "guix: Build depends/qt with our platform definition"
This reverts commit dc4137a.
* MS: restclient start
* MS: bumped c++ version from 14 to 17
* only gitian build for linux x86_64 for now. We can add back aarch64 later when needed.
* Testing whether OSX SDK needs to updated for gitian building for c++17
* test if bitcoins last gitian-build method works with unigrid
* yaml format error
* updated darwin host file for py build gitian
* Update depends make to work with latest build
* update darwin builder for new gitian
* DOWNLOAD_RETRIES:=3 readded for curl
* linux host update gitian
* check in default depends
* upgrade dawrwin to 19
* use focal
* remove i686 windows gitian
* testing whether jammy has same compile error for osx cctools
* switch back to focal
* place guix in proper directory
* guix util file
* guix util file
* lief is failing on guix build. try a newer version
* change hash for lief
* try and downgrade lief
* lief hash
* update darwin to never xcode version and osx 10.15 minimum
* added missing native_clang depends
* test jammy build focal cannot find repos
* missing some jammy in build.py
* build with kinetic
* focal appears to be the only docker container that builds correctly
* test building with g++9 linux
* test if reverting to c++14 builds work
* upgrade build.sh to use focal base VM. Remove some uneeded dependencies for linux builds.
* use jammy for builds and test building with c++17 or 20 if available
* force c++17
* don't check clock_gettime by default
* docker still cannot find ubuntu jammy revert to focal
* fdelt is required
* aarch64 required to compile
* disable arm build
* test disable glib backward support
* darwin builds were missing libtapi. native_cdrkit replaced with xorriso.
* change order of native_libtapi
* libtapi and clang are split out of cctools
* darwin unable to find glibtoolize
* upgrading boost and remove references to specific darwin versions
* split boost into build/host
* boost fail build on linux
* define minimum required boost
* adding missing required boost libraries after updating boost version
* errors building with boost 1.73.0 revert back to 1.71.0
* wrong xcode version in darwin build
* up boost version to 1.73.0
* test building with boost 1.80.0
* remove unused dependency and set min boost version
* upgrading boost requires more refactoring
* test if building osx works with c++11
* c++11 build fails on the rest client test to see if c++17 resolves this error
* accidental edit of robin-hood submodule
* use 12.2 osx sdk
* use 12.2 osx sdk for gitian-builder
* proper cheksum of Xcode
* checksum was not correct
* remove downloaded sdk
* attempted build with boost 1.80
* revert to c++14 and downgrade boost
* configure.ac set c++14
* Ms restclient (#5)
* MS: Updated univalue lib to latest version. Fixed parsing of json from restclient
* ms: added -hport as an argument in for unigridd.
* ms: added mint class to handel values from hedgehog. did some cleanup.
* ms: fixed compilation error
* ms: rewrote the rest client so its now working and getting json data from hedgehog
* ms: removed auto keyword
* ms: changed return type to bool to check if data got tranferd as expected from hedgehog
* ms: reverted c++ version to 14 from 17
Co-authored-by: Fim-84 <marcus.stenberg@gmail.com>
* set depends to build with c++11
* compile cc++ test update
* revert to old method of building boost that worked on OSX
* remove native_b2 ref
* remove native_cdrkit
* build ref for native_libtapi
* misisng endif
* try bitcoin boost build method
* errors compiling openssl with xcode 12.2 revert to 12.1
* test if old gitian build works with rest client update
* revert boost to old build
* reverting native cc tools build
* revert depends make to master
* missing cdrkit added
* cdrkit in wrong directory
* revert darwin host
* remove updated gitian build script from this branch. If we decide to stick with gitian this can be pulled from the EG_uposx_12_1 branch.
Co-authored-by: Carl Dong <contact@carldong.me>
Co-authored-by: fanquake <fanquake@gmail.com>
Co-authored-by: W. J. van der Laan <laanwj@protonmail.com>
Co-authored-by: Hennadii Stepanov <32963518+hebasto@users.noreply.github.com>
Co-authored-by: Andrew Chow <achow101-github@achow101.com>
Co-authored-by: Pieter Wuille <pieter@wuille.net>
Co-authored-by: h <harshit_goyal333@outlook.com>
Co-authored-by: jonatack <jon@atack.com>
Co-authored-by: Jeremy Rand <jeremyrand@airmail.cc>
Co-authored-by: Cory Fields <cory-nospam-@coryfields.com>
Co-authored-by: Pavol Rusnak <pavol@rusnak.io>
Co-authored-by: laanwj <126646+laanwj@users.noreply.github.com>
Co-authored-by: josibake <josibake@protonmail.com>
Co-authored-by: Stacie <staciewaleyko@gmail.com>
Co-authored-by: Fim-84 <marcus.stenberg@gmail.com>
dekm
added a commit
to unigrid-project/daemon
that referenced
this pull request
Nov 12, 2022
* rest client (#6) * guix: Add guix-verify script * guix-attest: Only use cross-platform flags for find+xargs * guix-attest: Use ascii-armor signatures * guix-attest: Allow skipping GPG signing with NO_SIGN * guix: Minor quoting fix in libexec/build.sh * guix: Construct $OUTDIR in ${DISTSRC}/output While files are being output to $OUTDIR, it will be under ${DISTSRC}/output, and only when everything is done, will ${DISTSRC}/output be moved to the actual $OUTDIR. This makes it so that a Ctrl-C in the middle of a build is less likely to result in a partially-constructed $OUTDIR. In fact, if I understand correctly, if $OUTDIR and $DISTSRC reside on the same filesystem, the move (rename) is likely atomic. Also, since the "working $OUTDIR" is under ${DISTSRC}/output, it will be cleaned properly by the guix-clean script. * guix: Attest to inputs in inputs.SHA256SUMS At build/codesigning-time, hash build inputs and output the digest to ${OUTDIR}/inputs.SHA256SUMS, which gets included in the final SHA256SUMS constructed by guix-attest. Example final SHA256SUMS: ee832d2a35b7701bff581dea05a536118b118e3ad0a587a2855b6ee8cd6fba20 inputs/bitcoin-78199266af7b.tar.gz ca765e70a0c12866dd63c0be228b675278a26329e5f8f5b5c52fd09200fedf21 bitcoin-78199266af7b-powerpc64le-linux-gnu-debug.tar.gz dae95327d7f2c324e2728c4b73627be6cb2c0d2f2e5bea940d1d5e6463939327 bitcoin-78199266af7b-powerpc64le-linux-gnu.tar.gz * guix: Skip attesting to dist-archive We already attest to the relevant dist-archive in inputs.SHA256SUMS, which is recorded at build-time. We use a SKIPATTEST.TAG file to indicate output directories which do not require attestation (much like the CACHEDIR.TAG specification). Generally, it's better to have build scripts declare properties of directories instead of introducing name-based special cases in attest scripts since build scripts have a more detailed context of what is going on. * guix: Consistently use gcc-8 for $HOST * guix-attest: Avoid incomplete sigdirs with ERR traps Sometimes GPG connects to the wrong agent... or you don't have your smartcard handy... * guix: install LIEF in Guix container Co-authored-by: Carl Dong <contact@carldong.me> * build: Makes rcc output always deterministic The Qt Resource Compiler (rcc) has a command-line option `--format-version` which has the default value 2. The only difference from `--format-version 1` is adding a last modified timestamp to the output file. That, in turn, forces us to use `QT_RCC_SOURCE_DATE_OVERRIDE=1` to get deterministic builds. This change makes rcc output always deterministic by using `--format-version 1` option that makes usage of the `QT_RCC_SOURCE_DATE_OVERRIDE` needless. Also it improves interaction with ccache. Co-authored-by: fanquake <fanquake@gmail.com> * guix: Reindent existing manifest.scm * guix: Package codesigning tools * guix: Add codesigning functionality * guix: repro: Sort find output in libtool for gcc-8 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 * guix: Remove dest if OUTDIR mv fails * guix: Check for disk space availability before building * Use latest signapple commit Update gitian and guix to use the same latest signapple commit * Make SHA256SUMS fragment right after build * Rewrite guix-{attest,verify} for new hier * scripts: LIEF 0.11.5 * guix-attest: Error out if SHA256SUMS is unexpected * guix: Rebase toolchain on glibc 2.24 (2.27 for riscv64) 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. * guix: Build depends/qt with our platform definition Our 'bitcoin-linux-g++' definition better integrates with our depends system than the stock linux-g++-64 definition. This fixes a bug whereby Guix builds on x86_64 for x86_64 did not produce a QMinimalIntegrationPlugin and led to bitcoin-qt not being built. * guix: Also sort SHA256SUMS.part * guix: no-longer pass --enable-glibc-back-compat to Guix Now that our Guix builds are performed on glibc 2.24 and 2.27 (RISCV), we no-longer need to pass the --enable-glibc-back-compat option. Replace it with --disable-threadlocal, to prevent the usage of symbols from glibc 2.18. None of the binaries produced required symbols later than 2.17, and 2.27 (RISCV). * guix: add additional documentation to patches * Avoid GCC 7.1 ABI change warning in guix build * guix: Patch binutils to add security-related disable flags 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. * guix: Test security-check sanity before performing them * guix: Check for a sane services database On bare systems, it is possible to be lacking a services database. Check for basic entries before attempting a build. See the error message in the diff for more context. * guix: Update various check_tools lists * guix: Pin kernel header version - Use 4.19 for riscv64 (earliest LTS release w/ riscv64 support) - Use 4.9 for all others (second-oldest LTS release, released in combination with glibc glibc 2.24 in Debian stretch) * guix: Bump to version-1.3.0 from upstream The chosen commit is the HEAD of Guix's version-1.3.0 branch as of July 15th, 2021. Also fix visual indenting. * guix: Overhaul README - Added detailed Guix bootstrap/installation instructions * guix-attest: Produce and sign normalized documents That way we can easily combine the document and detached signature to produce cleartext signature files for upload during the release process. See subsequent commits which modify doc/release-process.md for more details. * guix/INSTALL: Add coreutils/inotify-dir-recreate troubleshooting * guix/INSTALL: Guix installs init scripts in libdir * guix: Silence getent(1) invocation * guix/INSTALL: Misc fixups * guix/build: Remove vestigial SKIPATTEST.TAG * guix: Make all.SHA256SUMS rather than codesigned.SHA256SUMS * guix: Allow changing the base manifest in guix-verify When verifying guix attestations, it is useful to set a particular signer's manifest as the base to compare against. * Updated Readme, Corrected the codesign typo * script, doc: guix touchups * guix: Remove extra \r from all.SHA256SUMS line ending guix-attest mistakenly added an extra \r to the line endings in all.SHA256SUMS, causing guix-verify to erroneously fail. Co-Authored-By: Carl Dong <contact@carldong.me> * guix: Ensure EPOCH_SOURCE_DATE does not include GPG information If the user has set log.showSignature=true in their git config, then the git log will always output GPG signature information. Since git log is used to set EPOCH_SOURCE_DATE, this will mistakenly have GPG signature information in it which causes issues for the build. To avoid this issue, we override the config and force log.showSignature=false. * release: Release with separate SHA256SUMS and sig files This allows us to remove the rfc4880 EOL hacks and release with a SHA256SUMS.asc file that's a combination of all signer signatures. * guix-verify: Non-zero exit code when anything fails Previously, if verification fails, the correct message will be printed, but the exit code would still be 0. * guix: Don't include directory name in SHA256SUMS The SHA256SUMS file can be used in a sha256sum -c command to verify downloaded binaries. However users are likely to download just a single file and not place this file in the correct directory relative to the SHA256SUMS file for the simple verification command to work. By not including the directory name in the SHA256SUMS file, it will be easier for users to verify downloaded binaries. Co-authored-by: Carl Dong <contact@carldong.me> * guix/prelude: Override VERSION with FORCE_VERSION Previously, if the builder exported $VERSION in their environment (as past Gitian-building docs told them to), but their HEAD does not actually point to v$VERSION, their build outputs will differ from those of other builders. This is because the contrib/guix/guix-* scripts only ever act on the current git worktree, and does not try to check out $VERSION if $VERSION is set in the environment. Setting $VERSION only makes the scripts pretend like the current worktree is $VERSION. This problem was seen in jonatack's attestation for all.SHA256SUMS, where only his bitcoin-22.0rc3-osx-signed.dmg differed from everyone else's. Here is my deduced sequence of events: 1. Aug 27th: He guix-builds 22.0rc3 and uploads his attestations up to guix.sigs 2. Aug 30th, sometime after POSIX time 1630310848: he pulls the latest changes from master in the same worktree where he guix-built 22.0rc3 and ends up at 7be143a 3. Aug 30th, sometime before POSIX time 1630315907: With his worktree still on 7be143a, he guix-codesigns. Normally, this would result in outputs going in guix-build-7be143a960e2, but he had VERSION=22.0rc3 in his environment, so the guix-* scripts pretended like he was building 22.0rc3, and used 22.0rc3's guix-build directory to locate un-codesigned outputs and dump codesigned ones. However, our SOURCE_DATE_EPOCH defaults to the POSIX time of HEAD (7be143a), which made all timestamps in the resulting codesigned DMG 1630310848, 7be143a's POSIX timestamp. This differs from the POSIX timestamp of 22.0rc3, which is 1630348517. Note that the windows codesigning procedure does not consider SOURCE_DATE_EPOCH. We resolve this by only allowing VERSION overrides via the FORCE_VERSION environment variable. * build: set OSX_MIN_VERSION to 10.15 This is required to use std::filesystem on macOS as support for it only landed in the libc++ dylib shipped with 10.15. See also: https://developer.apple.com/documentation/xcode-release-notes/xcode-11-release-notes Clang now supports the C++17 <filesystem> library for iOS 13, macOS 10.15, watchOS 6, and tvOS 13. * Enable TLS in links in documentation * Integrate univalue into our buildsystem This addresses issues like the one in bitcoin#12467, where some of our compiler flags end up being dropped during the subconfigure of Univalue. Specifically, we're still using the compiler-default c++ version rather than forcing c++17. We can drop the need subconfigure completely in favor of a tighter build integration, where the sources are listed separately from the build recipes, so that they may be included directly by upstream projects. This is similar to the way leveldb build integration works in Core. Core benefits of this approach include: - Better caching (for ex. ccache and autoconf) - No need for a slow subconfigure - Faster autoconf - No more missing compile flags - Compile only the objects needed There are no benefits to Univalue itself that I can think of. These changes should be a no-op there, and to downstreams as well until they take advantage of the new sources.mk. This also removes the option to use an external univalue to avoid similar ABI issues with mystery binaries. Co-authored-by: fanquake <fanquake@gmail.com> * guix: Fix powerpc64(le) dynamic linker name I used Guix's values for the powerpc64(le) dynamic linkers, and the /lib-prefix seems to be a Guix-ism rather than standard. The standard path for the linker-loaders start with /lib64. I've taken the new loader values from SYSDEP_KNOWN_INTERPRETER_NAMES in glibc's sysdeps/unix/sysv/linux/powerpc/ldconfig.h file. For future reference, loader path values can also be found on glibc's website: https://sourceware.org/glibc/wiki/ABIList?action=recall&rev=16 * build: require glibc 2.18+ for release builds From what I can see the only platform this drops support for is CentOS 7. CentOS 7 reached the end of it's "full update" support at the end of 2020. It does receive maintenance updates until 2024, however I don't think supporting glibc 2.17 until 2024 is realistic. Note that anyone wanting to self-compile and target a glibc 2.17 runtime could build with --disable-threadlocal. glibc 2.18 was released in August 2013. https://sourceware.org/legacy-ml/libc-alpha/2013-08/msg00160.html * scripted-diff: Drop Darwin version for better maintainability -BEGIN VERIFY SCRIPT- sed -i 's/darwin19/darwin/g' $(git grep --files-with-matches 'darwin19') -END VERIFY SCRIPT- * test: Make more shell scripts verifiable by the `shellcheck` tool * test: Bump shellcheck version to 0.8.0 * scripted-diff: Insert missed copyright headers -BEGIN VERIFY SCRIPT- ./contrib/devtools/copyright_header.py insert contrib/guix/libexec/build.sh ./contrib/devtools/copyright_header.py insert contrib/guix/libexec/codesign.sh ./contrib/devtools/copyright_header.py insert contrib/tracing/log_raw_p2p_msgs.py ./contrib/devtools/copyright_header.py insert contrib/tracing/log_utxocache_flush.py ./contrib/devtools/copyright_header.py insert contrib/tracing/p2p_monitor.py ./contrib/devtools/copyright_header.py insert test/lint/lint-files.sh -END VERIFY SCRIPT- * build: use a static .tiff for macOS .dmg over generating Co-authored-by: Pavol Rusnak <pavol@rusnak.io> * guix: use GCC 10 (over GCC 8) to build releases This currently points to the version-1.4.0 branch. * guix: use uptream nsis-x86_64 Our patch is now used upstream. * build: use python-asn1crypto from upstream It is the exact same package definition. * guix: use upstream python-requests (2.26.0) Upstream python requests is now modern enough to be used as a dependency for signapple. Which requires requests>=2.25.1. * build: Point Guix to the current top of the "version-1.4.0" branch * build: point to latest commit on the master branch The version-1.4.0 branch no-longer exists, and will be branched off master again shortly. * guix: ignore additioanl failing certvalidator test ====================================================================== ERROR: test_revocation_mode_soft (tests.test_validate.ValidateTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/tmp/guix-build-python-certvalidator-0.1-1.e5bdb4b.drv-0/source/tests/test_validate.py", line 85, in test_revocation_mode_soft validate_path(context, path) File "/tmp/guix-build-python-certvalidator-0.1-1.e5bdb4b.drv-0/source/tests/../certvalidator/validate.py", line 50, in validate_path return _validate_path(validation_context, path) File "/tmp/guix-build-python-certvalidator-0.1-1.e5bdb4b.drv-0/source/tests/../certvalidator/validate.py", line 358, in _validate_path raise PathValidationError(pretty_message( certvalidator.errors.PathValidationError: The path could not be validated because the end-entity certificate expired 2022-01-14 12:00:00Z * build: Fix xargs warnings for Guix builds * build: use macOS 11 SDK (Xcode 12.2) This should be sufficient to support building for Apple ARM when cross-compiling. * guix: use autoconf 2.71 This allows for building with newer targets, like arm64-apple-darwin, due to having a newer bundled config.guess and config.sub. * guix: add arm64-apple-darwin triplet * build: Fix gcc-cross-x86_64-w64-mingw32-10.3.0 in Guix * build: Point Guix to recent commit on the master branch * Replace "can not" with "cannot" in docs, user messages, and tests * guix: use same commit for codesigning time-machine The time machines should be updated in lockstep. * build: Move guix time machine to prelude This deduplicates some code, and enforces consistency of the time machine configuration between scripts. * guix: only use native GCC 7 toolchain for Linux builds The macOS and Windows builds do not require a GCC 7 toolchain, and this is actually causing build issues, i.e bitcoin#24211. So switch to using a GCC 10 native toolchain for both. * guix: use latest upstream python-certvalidator This should also allow re-enabling previously failing tests. * guix: use latest upstream signapple This should improve support for signing for M1 binaries. * guix: Drop unneeded openssl dependency for signapple * guix: use latest signapple * guix: only check for the macOS SDK once If we are building for both macOS HOSTS, there's no need to check and print that the SDK exists two times. * guix: Use $HOST instead of generic osx{64} for macOS artifacts * guix: make it possible to override gpg binary For example on Qubes OS one might want to use qubes-gpg-client-wrapper instead * guix: Drop "-signed" suffix for signed macOS .dmg files This change makes naming of the signed artifacts consistent across different OSes, including Windows. * guix: Use "win64" for Windows artifacts consistently * Update signapple for platform identifier fix * doc, guix: Include arm64-apple-darwin into codesigned archs * guix: point to latest upstream commit * Revert "build: Fix gcc-cross-x86_64-w64-mingw32-10.3.0 in Guix" This reverts commit 7f2f35f. * macdeploy: remove unused detached-sig-apply Signature application is now done with signapple. * guix: Drop code for the unsupported `i686-linux-gnu` host Now GUIX build for the `i686-linux-gnu` host is broken, and there are no plans to re-add it. * contrib: use LIEF 0.12.0 for symbol and security checks * build: Fix "ERR: Unsigned tarballs do not exist" * guix: fix vmov alignment issues with gcc 10.3.0 & mingw-w64 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 bitcoin#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 bitcoin#24726. Alternative to bitcoin#24727. See also: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939559 * build: don't compress macOS DMG * guix: fix GCC 10.3.0 + mingw-w64 setjmp/longjmp issues 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: bitcoin-core/gui#582. See also: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=e8d1ca7d2c344a411779892616c423e157f4aea8. https://bugreports.qt.io/browse/QTBUG-93476. * guix: Improve error message about missed macOS SDK * guix: consolidate kernel headers to 5.15 Given no reason to use an older version of the kernel headers for the non-RISCV linux builds, consolidate all Linux builds to 5.15.x. Note that using older kernel headers isn't some sort of compatibility "hack", and glibc explicitly recommends against doing so. See: https://sourceware.org/glibc/wiki/FAQ#What_version_of_the_Linux_kernel_headers_should_be_used.3F. * build: include bitcoin.conf in build outputs copy over bitcoin.conf during the build process. this means `contrib/devtools/gen-bitcoin-conf.sh` will need to be run and the generated file committed during the release process. this is the same process used for generating man pages for each release. * guix: bump time-machine to 998eda3067c7d21e0d9bb3310d2f5a14b8f1c681 There are two reasons to perform this bump: * Fixes bitcoin#25082 by bumping to a commit that includes a fix for time-dependent unit tests in libgit2 (f5fe0082abe4547f3fb9f29d8351473cfb3a387b). * Gives us access to clang-toolchain-14 (14.0.3, 998eda3067c7d21e0d9bb3310d2f5a14b8f1c681), which is useful for the Guix portion of bitcoin#21778. Note that with this bump: Linux kernels headers update from 5.15.28 to 5.15.37. * guix: compile glibc without -werror Compiling glibc 2.24 and 2.27 with the new GCC 10 results in a number of new warnings, i.e: ```bash libc-tls.c: In function ‘__libc_setup_tls’: libc-tls.c:208:30: error: array subscript 1 is outside the bounds of an interior zero-length array ‘struct dtv_slotinfo[0]’ [-Werror=zero-length-bounds] 208 | static_slotinfo.si.slotinfo[1].map = main_map; | ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~ In file included from ../sysdeps/x86_64/ldsodefs.h:54, from ../sysdeps/gnu/ldsodefs.h:46, from ../sysdeps/unix/sysv/linux/ldsodefs.h:25, from libc-tls.c:20: ../sysdeps/generic/ldsodefs.h:398:7: note: while referencing ‘slotinfo’ 398 | } slotinfo[0]; | ^~~~~~~~ ``` While we could try and backport all the patches required to fix these up, it would currently seem easier to disable -Werror, which Guix uses by default when building glibc. * guix: adjust RISC-V __has_include() patch to work with GCC 10 The actual macro is __has_include(), not __has_include__(), using the later would result in build failures when using GCC 10. i.e: ```bash ../sysdeps/unix/sysv/linux/riscv/flush-icache.c:24:5: warning: "__has_include__" is not defined, evaluates to 0 [-Wundef] 24 | #if __has_include__ (<asm/syscalls.h>) ``` Looks like at least someone else has run into the same thing, see: http://lists.busybox.net/pipermail/buildroot/2020-July/590376.html. See also: https://gcc.gnu.org/onlinedocs/cpp/_005f_005fhas_005finclude.html https://clang.llvm.org/docs/LanguageExtensions.html#has-include * guix: fix glibc 2.27 multiple definition warnings with GCC 10 * guix: use -fcommon when building glibc 2.24 GCC 10 started using -fno-common by default, which causes issues with the powerpc builds using gibc 2.24. A patch was commited to glibc to fix the issue, 18363b4f010da9ba459b13310b113ac0647c2fcc but is non-trvial to backport, and was broken in at least one way, see the followup in commit 7650321ce037302bfc2f026aa19e0213b8d02fe6. For now, retain the legacy GCC behaviour by passing -fcommon when building glibc 2.24. https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html. https://sourceware.org/git/?p=glibc.git;a=commit;h=18363b4f010da9ba459b13310b113ac0647c2fcc https://sourceware.org/git/?p=glibc.git;a=commit;h=7650321ce037302bfc2f026aa19e0213b8d02fe6 * guix: native GCC 10 toolchain for Linux builds * guix: re-revert riscv execstack workaround Now that we use GCC 10 for release builds, we no-longer need to pass-Wl,-z,noexecstack to get a non-executable stack in RISC-V binaries. This was originally removed in bitcoin#21036, but then re-added in bitcoin#21799, when we reverted to using GCC 8. * guix: use libtool 2.4.7 As of version 2.4.7, libtool now respects ARFLAGS, which we use, and has changed the default ARFLAGS from cru to cr (which we also do, see configure). This eliminates spammy `ar` output such as: ```bash CXXLD libunivalue.la /root/.guix-profile/bin/x86_64-linux-gnu-ar: `u' modifier ignored since `D' is the default (see `U') AR libbitcoin_zmq.a AR libbitcoin_consensus.a CXXLD crypto/libbitcoin_crypto_base.la CXXLD crypto/libbitcoin_crypto_sse41.la /root/.guix-profile/bin/x86_64-linux-gnu-ar: `u' modifier ignored since `D' is the default (see `U') /root/.guix-profile/bin/x86_64-linux-gnu-ar: `u' modifier ignored since `D' is the default (see `U') CXXLD crypto/libbitcoin_crypto_avx2.la CXXLD crypto/libbitcoin_crypto_x86_shani.la CXXLD leveldb/libleveldb.la /root/.guix-profile/bin/x86_64-linux-gnu-ar: `u' modifier ignored since `D' is the default (see `U') CXXLD crc32c/libcrc32c.la /root/.guix-profile/bin/x86_64-linux-gnu-ar: `u' modifier ignored since `D' is the default (see `U') CXXLD leveldb/libmemenv.la /root/.guix-profile/bin/x86_64-linux-gnu-ar: `u' modifier ignored since `D' is the default (see `U') /root/.guix-profile/bin/x86_64-linux-gnu-ar: `u' modifier ignored since `D' is the default (see `U') /root/.guix-profile/bin/x86_64-linux-gnu-ar: `u' modifier ignored since `D' is the default (see `U') AR libbitcoin_cli.a ``` Libtool 2.4.7 release notes: https://lists.gnu.org/archive/html/autotools-announce/2022-03/msg00000.html * guix: remove explicit glibc stack protector disabling While glibc 2.25 and newer *can* be built with stack-smashing-protection enabled, it isn't used by default, and still isn't, as of glibc 2.35, so I can't see a reason to explicitly disable it. I'd also like to move in the direction of enabling, by default, hardening options for the toolchains we build, so removing the explicit disabling is a step in that direction. Will be following up with some changes based on this PR. * guix: parallelize LIEF build * guix: remove usage of -Wl,-z,noexecstack for PPC64 HOST The PPC64 ABI has a non-executable stack by default, and does not need a GNU_STACK program header. See also: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/include/asm/page_64.h#n92 * guix: use LIEF 0.12.1 * guix: patch LIEF to fix PPC64 NX default This patches our LIEF build using the change merged upstream: lief-project/LIEF#718. This can be dropped the next time we update LIEF. * guix: Map all guix store prefixes to /usr Without ffile-prefix-map, the debug symbols will contain paths for the guix store which will include the hashes of each package. However, the hash for the same package will differ when on different architectures. In order to be reproducible regardless of the architecture used to build the package, map all guix store prefixes to something fixed, e.g. /usr. * guix: Remove guix store paths from glibc Without ffile-prefix-map, the debug symbols will contain paths for the guix store which will include the hashes of each package. However, the hash for the same package will differ when on different architectures. In order to be reproducible regardless of the architecture used to build the package, map all guix store prefixes to something fixed, e.g. /usr. We might be able to drop this in favour of using --with-nonshared-cflags when we being using newer versions of glibc. * guix: use elfesteem 2eb1e5384ff7a220fd1afacd4a0170acff54fe56 Our patch has been merged upstream, see LRGH/elfesteem#3 * guix: patch gcc 10 with pthreads to remap guix store paths * guix: Drop repetition of option's default value * guix: enable SSP for RISC-V glibc (2.27) Pass `--enable-stack-protector=all` when building the glibc used for the RISC-V toolchain, to enable stack smashing protection on all functions, in the glibc code. * guix: pass enable-bind-now to glibc Both glibcs we build support `--enable-bind-now`: Disable lazy binding for installed shared objects and programs. This provides additional security hardening because it enables full RELRO and a read-only global offset table (GOT), at the cost of slightly increased program load times. See: https://www.gnu.org/software/libc/manual/html_node/Configuring-and-compiling.html * guix: enable hardening options in GCC Build Pass `--enable-default-pie` and `--enable-default-ssp` when configuring our GCCs. This achieves the following: --enable-default-pie Turn on -fPIE and -pie by default. --enable-default-ssp Turn on -fstack-protector-strong by default. Note that this isn't a replacement for passing hardneing flags ourselves, but introduces some redundency, and there isn't really a reason to not build a more "hardenings enabled" toolchain by default. See also: https://gcc.gnu.org/install/configure.html * guix: ignore additional failing certvalidator test Similar to 8588591. ```bash ERROR: test_revocation_mode_soft (tests.test_validate.ValidateTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/tmp/guix-build-python-certvalidator-0.1-1.a145bf2.drv-0/source/tests/test_validate.py", line 85, in test_revocation_mode_soft validate_path(context, path) File "/tmp/guix-build-python-certvalidator-0.1-1.a145bf2.drv-0/source/tests/../certvalidator/validate.py", line 50, in validate_path return _validate_path(validation_context, path) File "/tmp/guix-build-python-certvalidator-0.1-1.a145bf2.drv-0/source/tests/../certvalidator/validate.py", line 358, in _validate_path raise PathValidationError(pretty_message( certvalidator.errors.PathValidationError: The path could not be validated because the end-entity certificate expired 2022-07-27 12:00:00Z ``` * guix: patch NSIS to remove .reloc sections from install stubs With the release of binutils/ld 2.36, ld swapped to much improved default settings when producing windows binaries with mingw-w64. One of these changes was to stop stripping the .reloc section from binaries, which is required for working ASLR. .reloc section stripping is something we've accounted for previously, see bitcoin#18702. The related upstream discussion is in this thread: https://sourceware.org/bugzilla/show_bug.cgi?id=19011. When we switched to using a newer Guix time-machine in bitcoin#23778, we begun using binutils 2.37 to produce releases. Since then, our windows installer (produced with makensis) has not functioned correctly when run on a Windows system with the "Force randomization for images (Mandatory ASLR)" option enabled. Note that all of our other release binaries, which all contain .reloc sections, function fine under the same option, so it cannot be just the presence of a .reloc section that is the issue. For now, restore makensis to it's pre-binutils-2.36 behaviour, which fixes the produced installer. The underlying issue can be further investigated in future. * doc: minor updates to guix README * build: include share/rpcauth in tarball & installer Fixes bitcoin#19081. * guix: use --build={arch}-guix-linux-gnu in cross toolchain Technically we are always cross-compiling, so make that explicit. Fixes: bitcoin#22458. * guix: consistently use -ffile-prefix-map Aside from being the newer, more comprehensive option, it's what we claim to use in the patch docs, and everywhere else in guix. * guix: use git-minimal over git From the git-minimal package definition: > The size of the closure of 'git-minimal' is two thirds that of 'git'. > Its test suite runs slightly faster and most importantly it doesn't > depend on packages that are expensive to build such as Subversion. We don't need any fancy / additional git functionality above the basics, so switch to git-minimal and save some CPU, while also pruning the greater dependency graph. ```diff -name: git +name: git-minimal version: 2.37.3 outputs: -+ send-email: see Appendix H -+ svn: see Appendix H -+ credential-netrc: see Appendix H -+ credential-libsecret: see Appendix H -+ subtree: see Appendix H -+ gui: see Appendix H + out: everything else -systems: x86_64-linux mips64el-linux aarch64-linux powerpc64le-linux i686-linux armhf-linux powerpc-linux -dependencies: asciidoc@9.1.0 bash-minimal@5.1.8 bash@5.1.8 curl@7.79.1 docbook-xsl@1.79.2 expat@2.4.1 gettext-minimal@0.21 glib@2.70.2 libsecret@0.20.4 openssl@1.1.1l pcre2@10.37 perl-authen-sasl@2.16 perl-cgi@4.52 -+ perl-io-socket-ssl@2.068 perl-net-smtp-ssl@1.04 perl-term-readkey@2.38 perl@5.34.0 pkg-config@0.29.2 python@3.9.9 subversion@1.14.1 tcl@8.6.11 tk@8.6.11.1 xmlto@0.0.28 zlib@1.2.11 -location: gnu/packages/version-control.scm:222:2 +systems: x86_64-linux mips64el-linux aarch64-linux powerpc64le-linux riscv64-linux i686-linux armhf-linux powerpc-linux +dependencies: bash-minimal@5.1.8 bash@5.1.8 curl@7.79.1 expat@2.4.1 gettext-minimal@0.21 openssl@1.1.1l perl@5.34.0 zlib@1.2.11 +location: gnu/packages/version-control.scm:608:2 homepage: https://git-scm.com/ license: GPL 2 synopsis: Distributed version control system ``` * guix: Drop perl package * Revert "guix: Build depends/qt with our platform definition" This reverts commit dc4137a. * MS: restclient start * MS: bumped c++ version from 14 to 17 * only gitian build for linux x86_64 for now. We can add back aarch64 later when needed. * Testing whether OSX SDK needs to updated for gitian building for c++17 * test if bitcoins last gitian-build method works with unigrid * yaml format error * updated darwin host file for py build gitian * Update depends make to work with latest build * update darwin builder for new gitian * DOWNLOAD_RETRIES:=3 readded for curl * linux host update gitian * check in default depends * upgrade dawrwin to 19 * use focal * remove i686 windows gitian * testing whether jammy has same compile error for osx cctools * switch back to focal * place guix in proper directory * guix util file * guix util file * lief is failing on guix build. try a newer version * change hash for lief * try and downgrade lief * lief hash * update darwin to never xcode version and osx 10.15 minimum * added missing native_clang depends * test jammy build focal cannot find repos * missing some jammy in build.py * build with kinetic * focal appears to be the only docker container that builds correctly * test building with g++9 linux * test if reverting to c++14 builds work * upgrade build.sh to use focal base VM. Remove some uneeded dependencies for linux builds. * use jammy for builds and test building with c++17 or 20 if available * force c++17 * don't check clock_gettime by default * docker still cannot find ubuntu jammy revert to focal * fdelt is required * aarch64 required to compile * disable arm build * test disable glib backward support * darwin builds were missing libtapi. native_cdrkit replaced with xorriso. * change order of native_libtapi * libtapi and clang are split out of cctools * darwin unable to find glibtoolize * upgrading boost and remove references to specific darwin versions * split boost into build/host * boost fail build on linux * define minimum required boost * adding missing required boost libraries after updating boost version * errors building with boost 1.73.0 revert back to 1.71.0 * wrong xcode version in darwin build * up boost version to 1.73.0 * test building with boost 1.80.0 * remove unused dependency and set min boost version * upgrading boost requires more refactoring * test if building osx works with c++11 * c++11 build fails on the rest client test to see if c++17 resolves this error * accidental edit of robin-hood submodule * use 12.2 osx sdk * use 12.2 osx sdk for gitian-builder * proper cheksum of Xcode * checksum was not correct * remove downloaded sdk * attempted build with boost 1.80 * revert to c++14 and downgrade boost * configure.ac set c++14 * Ms restclient (#5) * MS: Updated univalue lib to latest version. Fixed parsing of json from restclient * ms: added -hport as an argument in for unigridd. * ms: added mint class to handel values from hedgehog. did some cleanup. * ms: fixed compilation error * ms: rewrote the rest client so its now working and getting json data from hedgehog * ms: removed auto keyword * ms: changed return type to bool to check if data got tranferd as expected from hedgehog * ms: reverted c++ version to 14 from 17 Co-authored-by: Fim-84 <marcus.stenberg@gmail.com> * set depends to build with c++11 * compile cc++ test update * revert to old method of building boost that worked on OSX * remove native_b2 ref * remove native_cdrkit * build ref for native_libtapi * misisng endif * try bitcoin boost build method * errors compiling openssl with xcode 12.2 revert to 12.1 * test if old gitian build works with rest client update * revert boost to old build * reverting native cc tools build * revert depends make to master * missing cdrkit added * cdrkit in wrong directory * revert darwin host * remove updated gitian build script from this branch. If we decide to stick with gitian this can be pulled from the EG_uposx_12_1 branch. Co-authored-by: Carl Dong <contact@carldong.me> Co-authored-by: fanquake <fanquake@gmail.com> Co-authored-by: W. J. van der Laan <laanwj@protonmail.com> Co-authored-by: Hennadii Stepanov <32963518+hebasto@users.noreply.github.com> Co-authored-by: Andrew Chow <achow101-github@achow101.com> Co-authored-by: Pieter Wuille <pieter@wuille.net> Co-authored-by: h <harshit_goyal333@outlook.com> Co-authored-by: jonatack <jon@atack.com> Co-authored-by: Jeremy Rand <jeremyrand@airmail.cc> Co-authored-by: Cory Fields <cory-nospam-@coryfields.com> Co-authored-by: Pavol Rusnak <pavol@rusnak.io> Co-authored-by: laanwj <126646+laanwj@users.noreply.github.com> Co-authored-by: josibake <josibake@protonmail.com> Co-authored-by: Stacie <staciewaleyko@gmail.com> Co-authored-by: Fim-84 <marcus.stenberg@gmail.com> * refactor of masternode to gridnode. Init will check for masternode.conf and rename the file to gridnode.conf on startup. * having issues with the ubuntu bionic installs. try with ubuntu jammy * remove uneeded break as we are not looping through strings anymore * increase GLIBC version for newer OS building * A complete refactor of the repo, to update Unigrid's naming convention of gridnodes instead of masternodes. * refactor additions for gridnodes vs masternodes * spelling error Gridnodeconfig * SPORK_20_UNDONKEY_MNREWARDS refactored :D * set build environment to bionic for gitian Co-authored-by: Carl Dong <contact@carldong.me> Co-authored-by: fanquake <fanquake@gmail.com> Co-authored-by: W. J. van der Laan <laanwj@protonmail.com> Co-authored-by: Hennadii Stepanov <32963518+hebasto@users.noreply.github.com> Co-authored-by: Andrew Chow <achow101-github@achow101.com> Co-authored-by: Pieter Wuille <pieter@wuille.net> Co-authored-by: h <harshit_goyal333@outlook.com> Co-authored-by: jonatack <jon@atack.com> Co-authored-by: Jeremy Rand <jeremyrand@airmail.cc> Co-authored-by: Cory Fields <cory-nospam-@coryfields.com> Co-authored-by: Pavol Rusnak <pavol@rusnak.io> Co-authored-by: laanwj <126646+laanwj@users.noreply.github.com> Co-authored-by: josibake <josibake@protonmail.com> Co-authored-by: Stacie <staciewaleyko@gmail.com> Co-authored-by: Fim-84 <marcus.stenberg@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Guix's
core-updates-frozenbranch has been merged back intomaster, and aversion-1.4.0branch has been created. This is great, as it means the next Guix release is on the horizon, and it contains a number of changes I'd like to take advantage of. In particular, is migrating the version of GCC we use for releases from GCC 8 to GCC 10.3.0 (which is also the new Guix default GCC). This is my preferred method of unblocking progress in #20744, which is currently stalled due to support forstd::filesystemfor Windows not arriving in GCC until version 9, whereas it's usable on Linux starting with GCC 8. The current set of changes in that PR attempt to backport support forstd::filesystem, for Windows, to GCC 8, similar to what is currently done by Debian, however that is somewhat convoluted, and using GCC 10 with our current Guix version would require updating at least one Guix patch to GCC, so is not completely straightforward either.Other changes included here:
--no-*patch for mingw binutils ld, as we can take advantage of the--disable-*flags that are now available in binutlils 2.37. The security check tests are updated accordingly.python-asn1cryptopackage definition, as an identical package is available in Guix. Over time we should look at trying to get the rest of the python packages we define here upstreamed.python-elfsteemto fix an issue in the example code when using Python 3.9+.2.24) now inherits from glibc-2.31. Guix has removed packages of glibc < 2.29, and the current version of glibc is2.33. However glibc-2.31 is the newest version that still contains a workaround for installing sunrpc data, which we need, so inheriting from that version seemed like the most straightforward solution.The guix commit hash currently points to the head of the
version-1.4.0branch. This can be updated to an official release tag when one is available.Looking for Concept ACKs on migrating to using GCC 10.3 for building releases. Keeping in mind issues like #20005, however that particular bug should be fixed in GCC 10.3.0+, according to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95189.
Guix Builds: