build一覧

Merge #19445: build: Update msvc build to use ISO standard C++17

<pre>Merge #19445: build: Update msvc build to use ISO standard C++17 2894e94d17e57dedad02ac34e217ab80bbd72ed6 Updates msvc build to use ISO standard C++17. (Aaron Clauson) Pull request description: This PR adds a compiler option to the msvc build to specify ISO C++17 support as discussed in #16684. In order to allow Bitcoin Core to compile with the new option two pre-processor defines are also necessary to avoid an warning (treated as an error) for C++17 deprecated features: - _SILENCE_CXX17_OLD_ALLOCATOR_MEMBERS_DEPRECATION_WARNING - _SILENCE_CXX17_CODECVT_HEADER_DEPRECATION_WARNING For anyone interested a sample compiler message for each of the warnings is shown below: ```` c:\Dev\github\sipsorcery_bitcoin\src\support\allocators\zeroafterfree.h(21,5): error C4996: 'std::allocator&lt;_Ty&gt;::const_pointer': warning STL4010: Various members of std::allocator are deprecated in C++17. Use std::allocator_traits instead of accessing these members directly. You can define _SILENCE_CXX17_OLD_ALLOCATOR_MEMBERS_DEPRECATION_WARNING or _SILENCE_ALL_CXX17_DEPRECATION_WARNINGS to acknowledge that you have received this warning. [c:\Dev\github\sipsorcery_bitcoin\build_msvc\libbitcoin_qt\libbitcoin_qt.vcxproj] ```` ```` c:\Dev\github\sipsorcery_bitcoin\src\fs.cpp(29,31): error C4996: 'std::codecvt_utf8_utf16&lt;wchar_t,1114111,(std::codecvt_mode)0&gt;': warning STL4017: std::wbuffer_convert, std::wstring_convert, and the &lt;codecvt&gt; header (containing std::codecvt_mode, std::codecvt_utf8, std::codecvt_utf16, and std::codecvt_utf8_utf16) are deprecated in C++17. (The std::codecvt class template is NOT deprecated.) The C++ Standard doesn't provide equivalent non-deprecated functionality; consider using MultiByteToWideChar() and WideCharToMultiByte() from &lt;Windows.h&gt; instead. You can define _SILENCE_CXX17_CODECVT_HEADER_DEPRECATION_WARNING or _SILENCE_ALL_CXX17_DEPRECATION_WARNINGS to acknowledge that you have received this warning. [c:\Dev\github\sipsorcery_bitcoin\build_msvc\libbitcoin_util\libbitcoin_util.vcxproj] ```` ACKs for top commit: MarcoFalke: Approach ACK 2894e94d17e57dedad02ac34e217ab80bbd72ed6 laanwj: ACK 2894e94d17e57dedad02ac34e217ab80bbd72ed6 Tree-SHA512: aff14726e05cb52f81dee32eafbd5b9ec829d3ed032ed4a03345458d6a22875a307ee8543952298a95d30d80720158586d33dbc8bf1970a99c403c3f1510d7fd</pre>

Merge #18307: build: Require pkg-config for all of the hosts

<pre>Merge #18307: build: Require pkg-config for all of the hosts 92bc268e4af4ebcbde08567ea00e019ac509a769 build: Detect missed pkg-config early (Hennadii Stepanov) 1739eb23d8a6d272e70f95342323b6fe48b8eb6c build: Drop unused use_pkgconfig variable (Hennadii Stepanov) a661449a2eeaf88efda36b6a84084dcbfe5b24eb build: Drop use_pkgconfig check for libmultiprocess check (Hennadii Stepanov) 90b95e7929463d6127c1b24fe1bf457d750a045c build: Drop dead non-pkg-config code for libevent check (Hennadii Stepanov) 44a14afbb889633a6c9a322a5aeca2e1b2cbdbd8 build: Drop dead non-pkg-config code for qrencode check (Hennadii Stepanov) 10cbae0c399302b0f8b1aa847c4246ba60bf25ee build: Drop dead non-pkg-config code for ZMQ check (Hennadii Stepanov) 06cfc9cadf7c5dd43147e6525a348d5f2d299422 build: Fix indentation in UNIVALUE check (Hennadii Stepanov) 6fd2118e777d11cbc81a45313d1a7d6400e34f3f build: Drop dead non-pkg-config code for UNIVALUE check (Hennadii Stepanov) e9edbe4dbd8c24a779de7d92e5f10c870aab5511 build: Always use pkg-config (Hennadii Stepanov) 9e2e753b0605c8cd826381a362f0c7de56eea81f build: Always define ZMQ_STATIC for MinGW (Hennadii Stepanov) Pull request description: This PR: - is based on #18297 (already merged) - drops all of the non-pkg-config paths from the `configure` script Ref: #17768 ACKs for top commit: fanquake: ACK 92bc268e4af4ebcbde08567ea00e019ac509a769. I re-gitian-built. There are a couple follow-ups that I'll PR shortly. Thanks for addressing my feedback above. I took too long to get back to this. laanwj: ACK 92bc268e4af4ebcbde08567ea00e019ac509a769 Tree-SHA512: 83c2d9cf03518867a1ebf7e26a8fc5b6dd8962ef983fe0d84e0c7eb74717f4c36a834da02faf0e503ffd87167005351671cf040c0d4ddae57ee152a6ff84012b</pre>

Merge #18288: build: Add MemorySanitizer (MSan) in Travis to detect u…

<pre>Merge #18288: build: Add MemorySanitizer (MSan) in Travis to detect use of uninitialized memory 870f0cd2a0534d54bba18190e9f024f88e832933 build: Add MemorySanitizer (MSan) in Travis to detect use of uninitialized memory (practicalswift) Pull request description: Add MemorySanitizer (MSan) in Travis to detect use of uninitialized memory. First UBSan, then ASan followed by TSan... and now: yes, the wait is over -- **MSan is finally here!** :) Some historical context: * 2017: Continuous compilation with Clang Thread Safety analysis enabled (#10866, #10923) * 2018: Continuous testing with trapping on signed integer overflows (`-ftrapv`) (#12686) * 2018: Continuous testing of use of locale dependent functions (#13041) * 2018: Continuous testing of format strings (#13705) * 2018: Continuous compilation with MSVC `TreatWarningAsError` (#14151) * 2018: Continuous testing under UndefinedBehaviorSanitizer &ndash; UBSan (#14252, #14673, #17006) * 2018: Continuous testing under AddressSanitizer &ndash; ASan (#14794, #17205, #17674) * 2018: Continuous testing under ThreadSanitizer &ndash; TSan (#14829) * 2019: Continuous testing in an unsigned char environment (`-funsigned-char`) (#15134) * 2019: Continuous compile-time testing of assumptions we're making (#15391) * 2019: Continuous testing of fuzz test cases under Valgrind (#17633, #18159, #18166) * 2020: Finally... MemorySanitizer &ndash; MSAN! :) What is the next step? What tools should we add to CI to keep bugs from entering `master`? :) ACKs for top commit: MarcoFalke: ACK 870f0cd2a0534d54bba18190e9f024f88e832933 Tree-SHA512: 38327c8b75679d97d469fe42e704cacd1217447a5a603701dd8a58ee50b3be2c10248f8d68a479ed081c0c4b254589d3081c9183f991640b06ef689061f75578</pre>

Merge #19375: build: target Windows 7 when building libevent and fix …

<pre>Merge #19375: build: target Windows 7 when building libevent and fix ipv6 usage eb6b73540d1ee7ff5a6874dd0e35f9b30b68e3b8 build: pass _WIN32_WINNT=0x0601 when building libevent for Windows (fanquake) 03e056edcd1a7f7197a29068c52fa33fce12f7d7 depends: Patch libevent build to fix IPv6 -rpcbind on Windows (Luke Dashjr) Pull request description: TLDR: This poaches a commit from #18287 and adds one more to adjust the Windows version targeted when building libevent. These changes combined should fully fix ipv6 usage with the RPC server on Windows. --- Binding the RPC server to a ipv6 address does not currently work on Windows. We currently try and bind to `127.0.0.1` and `::1` [by default](https://github.com/bitcoin/bitcoin/blob/master/src/httpserver.cpp#L304). On Windows you'll see lines like this in debug.log: ```bash 2020-06-24T01:49:04Z libevent: getaddrinfo: nodename nor servname provided, or not known 2020-06-24T01:49:04Z Binding RPC on address ::1 port 8332 failed ``` This issue was bought up in, and supposedly fixed by #18287, however the two people that tested it, both said that it didn't fix the problem. I think I now understand why that change alone is incomplete. Our call into libevent starts with [evhttp_bind_socket_with_handle()](https://github.com/bitcoin/bitcoin/blob/master/src/httpserver.cpp#L325): ```bash evhttp_bind_socket_with_handle() bind_socket() make_addrinfo() evutil_getaddrinfo() if #USE_NATIVE_GETADDRINFO #ifndef AI_ADDRCONFIG evutil_adjust_hints_for_addrconfig_() evutil_check_interfaces() evutil_check_ifaddrs() evutil_found_ifaddr() // miss identifies ipv6 as ipv4? #endif evutil_getaddrinfo_common_() ``` The problem is falling into ["#ifndef AI_ADDRCONFIG"](https://github.com/libevent/libevent/blob/master/evutil.c#L1580): ```cpp #ifndef AI_ADDRCONFIG /* Not every system has AI_ADDRCONFIG, so fake it. */ if (hints.ai_family == PF_UNSPEC &amp;&amp; (hints.ai_flags &amp; EVUTIL_AI_ADDRCONFIG)) { evutil_adjust_hints_for_addrconfig_(&amp;hints); } #endif ``` When this occurs, hints end up being adjusted, and it seems that ipv6 addresses end up being mis-identified as ipv4? However this shouldn't happen, as these `AI_` definitions are available on Windows. The issue is that in evutil.c, `_WIN32_WINNT` [is set to `0x501`](https://github.com/libevent/libevent/blob/master/evutil.c#L45) (XP). This obviously predates Vista (`0x0600`), which is when the `AI_ADDRCONFIG` definition (and others) became [available](https://docs.microsoft.com/en-us/windows/win32/api/ws2def/ns-ws2def-addrinfoa). The change here will override libevents internal D_WIN32_WINNT defines. This should be ok, because it's only making "more" of the Windows API available. It's also aligned with what we do in our own configure, we pass [`D_WIN32_WINNT=0x0601`](https://github.com/bitcoin/bitcoin/blob/master/configure.ac#L610). We also now use linker flags to restrict our binary from running on a Windows version [earlier than Windows 7](https://github.com/bitcoin/bitcoin/blob/master/configure.ac#L621). The combined fixes can be tested by running: `bitcoind -rpcbind=::1 rpcallowip='0.0.0.0/0' -debug=http` and then querying it using: `bitcoin-cli -rpcconnect=::1 getblockchaininfo` TODO: - [x] Open an issue upstream. https://github.com/libevent/libevent/issues/1041 ACKs for top commit: laanwj: ACK eb6b73540d1ee7ff5a6874dd0e35f9b30b68e3b8 Tree-SHA512: e1e50f194911301981edaed0c216ed4efb9ebd4a1f9bc9b9f85bec7140b66c45c8666fd5db4aad359596559d4a08ab7c920e9d9736f3ecdbb841afc54e40586e</pre>

Merge #19403: build: improve __builtin_clz* detection

<pre>Merge #19403: build: improve __builtin_clz* detection 9952242c03fe587b5dff46a9f770e319146103bf build: improve builtin_clz* detection (fanquake) Pull request description: Fixes #19402. The way we currently test for `__builtin_clz*` support with `AC_CHECK_DECLS` does not work with Clang: ```bash configure:21492: clang++-10 -std=c++11 -c -g -O2 -DHAVE_BUILD_INFO -D__STDC_FORMAT_MACROS conftest.cpp &gt;&amp;5 conftest.cpp:100:10: error: builtin functions must be directly called (void) __builtin_clz; ^ 1 error generated. ``` This also removes the `__builtin_clz()` check, as we don't actually use it anywhere, and it's trvial to re-add detection if we do start using it at some point. If this is controversial then I'll add a test for it as well. ACKs for top commit: sipa: ACK 9952242c03fe587b5dff46a9f770e319146103bf laanwj: ACK 9952242c03fe587b5dff46a9f770e319146103bf Tree-SHA512: 695abb1a694a01a25aaa483b4fffa7d598842f2ba4fe8630fbed9ce5450b915c33bf34bb16ad16a16b702dd7c91ebf49fe509a2498b9e28254fe0ec5177bbac0</pre>

Merge #19356: build: Fix search for brew-installed BDB 4 on OS X

<pre>Merge #19356: build: Fix search for brew-installed BDB 4 on OS X 8578c6fccd11404412d2c60f9bede311b79ca0d0 build: Fix search for brew-installed BDB 4 on OS X (Glenn Willen) Pull request description: ~~NOTE: This PR contains one important fix that I need (to make Bitcoin Core build cleanly on my system without shenanigans), plus some related general cleanup that is not really necessary, and could be annoying. (I am prepared to defend my argument that BDB_CFLAGS is wrong here, and BDB_CPPFLAGS is right, but this could bite anybody who has gotten in the habit of -- or scripted -- setting the former.)~~ Ok, I have been convinced that I was too clever with the refactor and I have removed it. Now it's just the tiny change to fix the build on my local machine. --- On OS X, when searching Homebrew keg-only packages for BDB 4.8, if we find it, use BDB_CPPFLAGS and BDB_LIBS instead of CFLAGS and LIBS for the result. This is (1) more correct, and (2) necessary in order to give this location priority over other directories in the include search path, which may include system include directories with other versions of BDB. ACKs for top commit: theuni: ACK 8578c6fccd11404412d2c60f9bede311b79ca0d0. Tree-SHA512: a28f48fc81a25736f7e77c663f21cd9a6ae1cd115682031c5aa695c94cb5afa11920330a60cd6a54832822a2aec1eb23123ac2e2dcd4f0b3835aef9c9339ac97</pre>

スポンサーリンク

トップへ戻る