Update Develop - #2
Open
lyricidal wants to merge 577 commits into
Open
Conversation
This is no longer needed after 3bef7c22 in the mingw-w64 git repository, which is first included in mingw-w64 v7.0.0. As of the previous bump to our Guix time machine, we now use mingw-w64 v7.0.0.
The libtool unsorted 'find' determinism issue seemed to have been solved in gcc-9's git: d41cd173e23ebea7c758644d6ad6e0fde1c2e3a6 or SVN: r262451 Furthermore, it seems that Ubuntu Focal 20.04 LTS is going to ship with gcc 9 and mingw-w64 7, which will match what we have now. ----- A note on this: Careful observers will see that previously I stated that all released versions of gcc were bootstrapped with a libtool 2.2.7a, meaning that they all had the unsorted 'find' determinism issue first resolved in libtool 2.2.7b. However, I was mistaken, gcc's ltmain.sh CLAIMS it was generated by libtool 2.2.7a, but it was in fact edited manually. It seems that gcc maintains their own versions of ltmain.sh and libtool.m4, and only sometimes backports patches from upstream. Quite confusing.
…-6.0.0 [Upstream] guix: Enable building for `x86_64-w64-mingw32` target
httpserver.cpp:74:10: error: no template named 'deque' in namespace 'std'
std::deque<std::unique_ptr<WorkItem>> queue;
~~~~~^
depends: boost 1.72
This directory is automatically created by the build process (in the build target directory, see bitcoin#16588) and doesn't need to be in the repository nor in the tarballs. Move associated ignore directive to top-level `.gitignore` file.
The build date does only makes sense for custom/self-compiled versions because we are using static build-dates for our deterministic release builds. Coming from btc@4856f1d6712cdb2eac8712e379fd1e351583d78f
Putting the build date in the executable is a practice that has no place in these days, now that deterministic building is increasingly common. Continues bitcoin/bitcoin#7732 which did this for the GUI.
[Upstream] [Build] Get rid of CLIENT_DATE
The Bitcoin Core NSIS script runs with elevated privileges. Unfortunately, this means that it launches Bitcoin Core itself with elevated privileges when the user chooses to launch Bitcoin Core at the end of the installation procedure. This commit works around the issue by having explorer.exe launch Bitcoin Core. Seems to be a similar approach to what http://nsis.sourceforge.net/ShellExecAsUser_plug-in does, but without a plugin. h/t to "UK" at https://mdb-blog.blogspot.se/2013/01/nsis-lunch-program-as-user-from-uac.html?showComment=1410158039989#c2463780017054126736 for the sample code. Fixes bitcoin/bitcoin#7990.
Now that we are using Focal for gitian builds, and have NSIS 3.0+ available (also in Guix), we can create installers that support unicode. Unicode is only becoming the default beginning with the 3.07 release, https://nsis.sourceforge.io/Docs/AppendixF.html#v3.07-cl, so we need to set this attribute to get support. Should close: bitcoin/bitcoin#13817
Otherwise a user can pass /NCRC on the command line and bypass the crc check, meaning they could install a potentially corrupted installer.
[Upstream] Avoid launching as admin when NSIS installer ends.
[Upstream] build: set Unicode true for NSIS installer
[Upstream] build: force CRCCheck in Windows installer
This allows the setting to be changed on the fly again, no longer requiring a restart. Value is checked on launch and set back to config anyway.
rpc: remove .conf file check for combinedust in autocombinedust
[Upstream] build: Fix `make deploy` for Windows when building out of source tree
build, qt: add libcurl 8.0.1, use for price fetch
tests: fix broken wallet test
build: use our own FALLBACK_DOWNLOAD_PATH for depends
depends: libcurl 8.4.0
Otherwise our config.guess and config.sub will be copied over. This problem has been masked by the fact that modern systems ship with versions that recognise all the triplets we use (namely arm64-apple-darwin). However building on ubuntu 20.04 surfaces the issue. Fixes bitcoin/bitcoin#26420.
[Upstream] build: copy config.{guess,sub} post autogen in zmq package
[Upstream] depends: zeromq 4.3.5
depends: libcurl 8.5.0
depends: zlib 1.3.1
[Trivial] Update copyright for 2024
Bumps [actions/download-artifact](https://github.com/actions/download-artifact) from 1 to 4.1.7. - [Release notes](https://github.com/actions/download-artifact/releases) - [Commits](actions/download-artifact@v1...v4.1.7) --- updated-dependencies: - dependency-name: actions/download-artifact dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com>
…ithub/workflows/actions/download-artifact-4.1.7 Bump actions/download-artifact from 1 to 4.1.7 in /.github/workflows
depends: zlib 1.3.2
[Trivial] Update copyright for 2026
The hosted ubuntu-20.04 runner was retired and the v1 artifact service shut down, leaving the build factory unable to run. Restore it: - run all jobs in an ubuntu:20.04 container on ubuntu-latest (same GCC 9 / glibc 2.31 toolchain as the last green builds), with a prepare step for the tools the hosted image provided (incl. libtinfo5, needed by the prebuilt darwin clang) - update actions to node24 releases: checkout@v5, upload-artifact@v6, download-artifact@v7 (v1 uploads are incompatible with v4+ downloads) - default run steps to bash: container jobs default to sh, which broke the brace expansions in the packaging steps - generate version.txt from configure.ac; the file was removed in "build: delete version.txt" but the workflows still read it - fix macOS SDK pin to Xcode 12.1-12A7403 to match depends/hosts/darwin.mk - add workflow_dispatch trigger for manual runs - drop the ubuntu-18.04 build-linux job (libssl1.0-dev/libdb4.8 are no longer installable; it duplicated the depends-based x86_64 build)
ci: fix build factory workflows
OpenSSL 1.1.0 removed the thread-locking callback API (CRYPTO_num_locks, CRYPTO_set_locking_callback, CRYPTO_LOCK) and RAND_screen(); util.cpp's CInit still used them, breaking the build against modern OpenSSL. Compile that block only for OpenSSL < 1.1.0 / LibreSSL (1.1 is internally thread-safe). Also disable the vendored secp256k1 / secp256k1-mw test suites in configure.ac (--enable-tests=no): their configure's SECP_OPENSSL_CHECK compiles an OpenSSL EC cross-check using the pre-1.1 EC_KEY/ECDSA_SIG API, which does not build against OpenSSL >= 1.1.0. The libraries themselves use no OpenSSL, so this is compile-only with no runtime/consensus effect. Re-run autogen.sh after applying.
The depends builder pinned OpenSSL 1.0.2u; many of its no-* config flags (no-ssl2, no-krb5, no-jpake, no-rsax, no-heartbeats, no-store, ...) do not exist in OpenSSL 1.1, so Configure rejects them. Update depends/packages/ openssl.mk to 1.1.1w: new version/sha256/download path, a 1.1-valid config_opts set (platform targets unchanged), the 1.1 preprocess steps (no Makefile.org), and DESTDIR= staging (1.1 renamed it from INSTALL_PREFIX=). Only affects depends/gitian/cross builds; no runtime or consensus effect.
qt.mk set one unconditional OPENSSL_LIBS that hardcoded the Windows-only
libraries -lws2_32 -lgdi32. Qt consumes OPENSSL_LIBS in its "openssl" config
test and the network-module link, so on Linux/macOS the test failed to link
("cannot find -lws2_32"), Qt set libs.openssl=no, and configure aborted with
"Feature 'openssl-linked' was enabled, but the pre-condition
'!features.securetransport && libs.openssl' failed". Split OPENSSL_LIBS per
host: mingw keeps its exact (working) value, Linux uses -lssl -lcrypto
-lpthread -ldl, and macOS uses -lssl -lcrypto. depends/gitian/cross builds
only; no runtime or consensus effect.
depends: openssl 1.1.1w
depends: Bump Qt version to 5.12.12
Backport of Bitcoin Core PR #9698 (theuni, "net: fix socket close race",
merged 2017-02-10), by way of the equivalent code in PIVX.
ThreadSocketHandler read pnode->hSocket while holding cs_vSend or
cs_vRecvMsg, but nothing stopped another thread from closing that socket
between the validity check at the top of the loop and the FD_SET() that used
it. ThreadMessageHandler -> PushMessage -> SocketSendData can hit a send
error, call CloseSocketDisconnect(), and leave hSocket == INVALID_SOCKET
while the socket handler is mid-pass.
Passing -1 to FD_SET() is not benign on glibc. With _FORTIFY_SOURCE the macro
goes through __fdelt_chk(), which aborts the process when the descriptor is
negative as well as when it is >= FD_SETSIZE, giving
*** buffer overflow detected ***: terminated
The abort happens during sync at no particular height, which is what made it
look like a data-dependent bug rather than a race.
hSocket now has its own mutex, cs_hSocket, held across every read and use of
the descriptor: in CloseSocketDisconnect(), around send() in SocketSendData(),
around the FD_SET() calls, and around recv() and the FD_ISSET() sampling.
As upstream does, cs_hSocket is the innermost lock. The decision of what to
select for is made under cs_vSend / cs_vRecvMsg first, those are released, and
only then is cs_hSocket taken. Taking them in the other order would invert
against SocketSendData(), which is called with cs_vSend already held.
net: fix socket close race (backport of Bitcoin Core #9698)
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.Suggestion cannot be applied right now. Please check back later.
No description provided.