Aplies a patch to Qt that fixes the non-determinism by modifying Qt. The
source of the non-determinism is how LLVM 8 optimizes qt_intersect_spans
when compiling. The particular optimization that seems to be causing the
problems is that a temp variable is being added for spans->y. For some
reason, when it does this, it chooses different instructions to use when
making that variable. We bypass this problem by patching
qt_intersect_spans to always make and use this local variable.
a52ecc936a build: set minimum supported macOS to 10.14 (fanquake)
Pull request description:
This is a requirement for C++17 support. See my comments [here](https://github.com/bitcoin/bitcoin/issues/16684#issuecomment-643722538):
> You cannot use std::get with std::variant on macOS < 10.14, because Apples libc++ doesn't support the std::bad_variant_access exception. [Relevant comment](https://github.com/bitcoin/bitcoin/pull/19183#discussion_r439794318) in #19183.
> While we could work around this in our own code, using std::get_if, this would still be a problem for 3rd-party dependencies.
> I've been testing Qt 5.15LTS (we'll have to enable C++17 in qt, and may upgrade to a newer version at the same time), and you can't enable -std c++17, while targeting a macOS deployment version < 10.14, configuring will fail. They are making use of std::get with std::variant throughout their cocoa code.
We would have to had to have bumped to at least 10.13 in any case, as Qt 5.15 (#19716) [requires 10.13+](https://doc.qt.io/qt-5/supported-platforms.html).
ACKs for top commit:
hebasto:
ACK a52ecc936a, I have reviewed the code and it looks OK, I agree it can be merged.
Tree-SHA512: f669b2fc777aeea1e9afdbbc7bd9afe3997418211db6ba53c934cae0e62a9b999603da539518c229f34961d275c9e2f315c7b022cf5fb97bd201a69c85d470cc
e1f2553e11 build: remove global_init_link_order from mac qt qmake.conf (fanquake)
498fa16bea build: document preprocessing steps in qt package (fanquake)
bd5d9336d9 build: don't copy Info.plist.* into mkspec for macOS qt build (fanquake)
bfd7e33b4b build: remove plugin_no_soname from mac qt qmake.conf (fanquake)
fdde4c7ce6 build: pass XCODE_VERSION through to qt macOS cross compile conf (fanquake)
49473ef211 build: convert "echo" usage into a patch in qt package (fanquake)
Pull request description:
Follow up on removing `sed` usage in #19761. Also nice to revisit & cleanup before 5.15.x.
ACKs for top commit:
laanwj:
Code review ACK e1f2553e11
Tree-SHA512: 4e6489d877aaa300f69e091d7117136da49611bd80afd45adfbd7ddeb5b3c9c76fb0f87a3249cbe63ba93129df56281fd4a9389daadc852211325c5ca9ac6567
7087440894 depends: native_ds_store 1.3.0 (fanquake)
Pull request description:
`ds_store` [now takes advantage](36fb607940) of Pythons ability to decode binary [plists](https://docs.python.org/3/library/plistlib.html) (since 3.4), so we can drop its biplist dependency.
The call to `biplist.Data()` in `custom_dsstore.py` doesn't seem to do anything, and from what I can tell can just be removed. i.e:
```diff
diff --git a/contrib/macdeploy/custom_dsstore.py b/contrib/macdeploy/custom_dsstore.py
index dc1c1882d..e475bc6c3 100755
--- a/contrib/macdeploy/custom_dsstore.py
+++ b/contrib/macdeploy/custom_dsstore.py
@@ -47,6 +47,7 @@ alias.volume.disk_image_alias.target.filename = package_name_ns + '.temp.dmg'
alias.volume.disk_image_alias.target.carbon_path = 'Macintosh HD:Users:\x00bitcoinuser:\x00Documents:\x00bitcoin:\x00bitcoin:\x00' + package_name_ns + '.temp.dmg'
alias.volume.disk_image_alias.target.posix_path = 'Users/bitcoinuser/Documents/bitcoin/bitcoin/' + package_name_ns + '.temp.dmg'
alias.target.carbon_path = package_name_ns + ':.background:\x00background.tiff'
+assert(biplist.Data(alias.to_bytes()) == alias.to_bytes())
icvp['backgroundImageAlias'] = biplist.Data(alias.to_bytes())
ds['.']['icvp'] = icvp
```
ACKs for top commit:
laanwj:
ACK 7087440894
Tree-SHA512: 8ba3cf561937efe4a3daae8b0cb4de3bf9e425b3a9244161b09d94ee2b1bd4c3e21315fa70e495b19a052aabdc1731b3b6f346b63272d72d2762ced83237d02f
This has been around since the original import of Qt
(38be0d13830efd2d98281c645c3a60afe05ffece), however there
are now only two instatnces of it left in the qt codebase,
and from what I can gather, it's unused.
We generate our own Info.plist as part of make deploy, and as far as I
can tell, it doesn't seem to have an effect wether these are present
during qt's build.
I also can't find a single mention of the .app plist in the qt code,
whereas there are multiple instances of .lib.
plugin_no_soname was removed from Qt some time ago, see upstream commit
1d034244c261520d5e739534dc264c2500e02b5f. It was replaced with
plugin_with_soname, however that is currently only used (as of 5.15.x)
in the Android Clang mkspec.
This should mostly be a no-op, however it would seem to make more sense
that we pass through the XCODE_VERSION we now have in depends, rather
than leaving the version set to 4.3.
native_ds_store now takes advantage of Pythons ability to decode binary
plists (since 3.4), so we can drop its biplist dependency.
The call to biplist.Data() in custom_dsstore doesn't seem to do anything,
and from what I can tell can just be removed.
Previously, when running ./configure:
1. With CONFIG_SITE pointed to our depends config.site.in, and
2. PYTHONPATH was not set either in the environment or by the user
The configure would output something like:
PYTHONPATH='depends/x86_64-pc-linux-gnu/share/../native/lib/python3/dist-packages:'
When we really mean:
PYTHONPATH='depends/x86_64-pc-linux-gnu/share/../native/lib/python3/dist-packages'
...without the colon
This change makes sure that:
1. There's no trailing colon, and
2. We use the $PATH_SEPARATOR variable instead of a colon
Files like config.site.in are not referenced by any other script in our
tree, so we need to mark it manually with a "shellcheck shell="
directive and make sure that shellcheck is run on them.
Previously, if ./configure was invoked with:
```
$ env CONFIG_SITE=depends/x86_64-pc-linux-gnu/share/config.site ./configure
```
Where $CONFIG_SITE was a relative path, ./configure would fail with the
following misleading output:
```
checking for boostlib >= 1.58.0 (105800)... yes
checking whether the Boost::System library is available... yes
configure: error: Could not find a version of the Boost::System library!
```
Fully resolving depends_prefix in config.site.in fixes this. To make
sure that there are no other side effects I ran a diff on the
config.status generated by:
1. The scripts prior to this change with CONFIG_SITE set to a full path:
env CONFIG_SITE=$PWD/depends/x86_64-pc-linux-gnu/share/config.site ./configure
2. The scripts after this change with CONFIG_SITE set to a relative path:
env CONFIG_SITE=depends/x86_64-pc-linux-gnu/share/config.site ./configure
And it looks good!
Diff: https://paste.sr.ht/~dongcarl/95b469fbc555c128046e85723d87a9082a754f6b
d0a829e963 build: fix mutex detection when building bdb on macOS (fanquake)
Pull request description:
Starting with the Apple Clang shipped with Xcode 12, [Apple has enabled -Werror=implicit-function-declaration by default](https://developer.apple.com/documentation/xcode-release-notes/xcode-12-release-notes):
> Clang now reports an error when you use a function without an explicit declaration when building C or Objective-C code for macOS (-Werror=implicit-function-declaration flag is on). This additional error detection unifies Clang’s behavior for iOS/tvOS and macOS 64-bit targets for this diagnostic. (49917738)
This causes bdbs mutex detection to fail when building on macOS (not cross-compiling):
```bash
checking for mutexes... UNIX/fcntl
configure: WARNING: NO SHARED LATCH IMPLEMENTATION FOUND FOR THIS PLATFORM.
configure: error: Unable to find a mutex implementation
```
as previously emitted warnings are being turned into errors. i.e:
```bash
configure:18704: checking for mutexes
configure:18815: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -mmacosx-version-min=10.12 --sysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -o conftest -pipe -O2 -I/Users/michael/github/fanquake-bitcoin/depends/x86_64-apple-darwin19.6.0/include -L/Users/michael/github/fanquake-bitcoin/depends/x86_64-apple-darwin19.6.0/lib conftest.c -lpthread >&5
conftest.c:46:1: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
main() {
^
conftest.c:51:2: error: implicitly declaring library function 'exit' with type 'void (int) __attribute__((noreturn))' [-Werror,-Wimplicit-function-declaration]
exit (
^
conftest.c:51:2: note: include the header <stdlib.h> or explicitly provide a declaration for 'exit'
1 warning and 1 error generated.
```
Append `-Wno-error=implicit-function-declaration` to `cflags` so that `-Wimplicit-function-declaration` [returns to being a warning](https://clang.llvm.org/docs/UsersManual.html#cmdoption-wno-error), and the configure checks succeed.
Fixes#19411.
ACKs for top commit:
laanwj:
Code review ACK d0a829e963
Tree-SHA512: 7813005b1fc0b370f843b6c0672acab32c999416e92c3f02b75d866e9c7aa41fe5822704fc74de6b65f0d7d94f2cdd05cc7c3ee83295ff1ecbc71d8492b9a2bf
Starting with the Clang shipped with Xcode 12, Apple has enabled
-Werror=implicit-function-declaration by default. This causes bdbs mutex
detection to fail when building on macOS (not cross-compiling):
checking for mutexes... UNIX/fcntl
configure: WARNING: NO SHARED LATCH IMPLEMENTATION FOUND FOR THIS PLATFORM.
configure: error: Unable to find a mutex implementation
as previously emitted warnings are being turned into errors. i.e:
error: implicitly declaring library function 'exit' with type 'void (int) __attribute__((noreturn))' [-Werror,-Wimplicit-function-declaration]
Append -Wno-error=implicit-function-declaration to cflags so that
-Wimplicit-function-declaration returns to being a warning, and the
configure checks will succeed.
Fixes#19411.
After #19685 started setting LDFLAGS, the INSTALL_RPATH_USE_LINK_PATH cmake
option used in the libmultiprocess build no longer works, so it is neccessary
to set CMAKE_INSTALL_RPATH as a fallback.
It's unclear currently whether the bad interaction between
INSTALL_RPATH_USE_LINK_PATH and LDFLAGS is a bug, but the issue is reported:
https://github.com/bitcoin/bitcoin/issues/19981#issuecomment-696680877https://discourse.cmake.org/t/install-rpath-use-link-path-not-working-when-cmake-exe-linker-flags-ldflags-is-set/1892
Commands useful for building / testing this change
make -C depends MULTIPROCESS=1 print-libmultiprocess_cmake
make -C depends MULTIPROCESS=1 print-native_libmultiprocess_cmake
make -C depends MULTIPROCESS=1 HOST=x86_64-apple-darwin16 print-libmultiprocess_cmake
rm -rvf depends/x86_64-pc-linux-gnu/native depends/work/staging depends/work/build
make -C depends MULTIPROCESS=1 V=1 native_libmultiprocess_staged
for f in `find -name mpgen`; do echo == $f ==; readelf -d $f | grep -i path; done
make -C depends MULTIPROCESS=1 V=1 native_libmultiprocess_built
find -name CMakeCache.txt
Fixes#19981
7a89f2e6c5 build: Fix target name (Hennadii Stepanov)
Pull request description:
It seems like a typo :)
This PR:
- fixes errors when building a package in depends for `HOST=x86_64-apple-darwin16` (fix#19799)
- is a correct alternative to d25e0e308f from #19764
ACKs for top commit:
icota:
tACK 7a89f2e6c5
dongcarl:
Code Review ACK 7a89f2e6c5
theuni:
ACK 7a89f2e6c5.
Tree-SHA512: a0bcbc6805d3450e201476ef1e22e0eb53903db1586c5515314c19afd337bded887e56de0fbe62feaf359b2de15dbccd49a44f1a8b566b4c64f5ae3d94a2ab6d
This is an alternative to #19751 that fixes the build without requiring
splitting out libpng. This patch can be dropped once we are building qt
5.12.0 or later.
b893688357 depends: Specify LDFLAGS to cmake as well (Carl Dong)
b3f541f618 depends: Prepend CPPFLAGS to C{,XX}FLAGS for CMake (Carl Dong)
8e121e5509 depends: Cleanup CMake invocation (Carl Dong)
8c7cd0c6d9 depends: More robust cmake invocation (Carl Dong)
3ecf0eca63 depends: Use $($(package)_cmake) instead of cmake (Carl Dong)
Pull request description:
- Use `$($(package)_cmake)` instead of invoking `cmake` directly
- Use well-known env vars instead of overriding CMake variables
ACKs for top commit:
ryanofsky:
Code review ACK b893688357. Only changes since last review are new commits adding whitespace, cppflags and ldflags to cmake invocation
Tree-SHA512: cfcd8cc9dcd0b336cf48b82fca9fe4bbc7930ed397cb7a68a07066680eb4c1906a6a9b5bd2589b4b4999e8f16232fa30ee9b376b60f4456d0fff931fbf9cc19a
The usage of pragmas within the macOS SDK requires LLVM Clang 8. This is
the version as our prebuilt Clang, however the minimum is worth noting here
as they may diverge and/or expert users might expect they could use an
earlier version.
If you compile using Clang 7 you'll see output like:
```bash
In file included from kernel/qcore_mac_objc.mm:44:
In file included from /bitcoin/depends/SDKs/Xcode-11.3.1-11C505-extracted-SDK-with-libcxx-headers/System/Library/Frameworks/AppKit.framework/Headers/NSText.h:9:
In file included from /bitcoin/depends/SDKs/Xcode-11.3.1-11C505-extracted-SDK-with-libcxx-headers/System/Library/Frameworks/AppKit.framework/Headers/NSView.h:19:
In file included from /bitcoin/depends/SDKs/Xcode-11.3.1-11C505-extracted-SDK-with-libcxx-headers/System/Library/Frameworks/AppKit.framework/Headers/NSResponder.h:10:
/bitcoin/depends/SDKs/Xcode-11.3.1-11C505-extracted-SDK-with-libcxx-headers/System/Library/Frameworks/AppKit.framework/Headers/NSEvent.h:19:1: error:
expected 'push' or 'pop' after '#pragma clang attribute'
/bitcoin/depends/SDKs/Xcode-11.3.1-11C505-extracted-SDK-with-libcxx-headers/usr/include/os/availability.h:104:273: note: expanded from macro
'API_UNAVAILABLE_BEGIN'
...__API_UNAVAILABLE_BEGIN5, __API_UNAVAILABLE_BEGIN4, __API_UNAVAILABLE_BEGIN3, __API_UNAVAILABLE_BEGIN2, __API_UNAVAILABLE_BEGIN1, 0)(__VA_A...
^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.
```
5962522fbc depends: bump native_cctools for fixed lto with external clang (Cory Fields)
00d1ba7aaa depends: enable lto support for Apple's ld64 (Cory Fields)
Pull request description:
This didn't work for a few reasons (various toolchain compatibility issues) the last time I tested it, but after the last round of bumps it works with no apparent issues.
Note that this does not _enable_ LTO by default in any way, only hooks up the machinery for ```-flto``` to work correctly when specified.
Lines were split for an easier rebase after #17919 is merged.
ACKs for top commit:
fanquake:
ACK 5962522fbc. The relevant option upstream is [here](https://github.com/tpoechtrager/cctools-port/blob/master/cctools/m4/llvm.m4#L4).
Tree-SHA512: df2775e74e7bc847e6cef94cb8457d503d6c9e2fdea861e51386fa6ed5a7ba688241db3685561ae1a32f66724c1b3801727252025f00c04b90a3bdc8a4f6f93b
2a701a1c42 build: pass -fcommon when building genisoimage (fanquake)
Pull request description:
Starting with the 10.1 release, GCC [defaults to -fno-common](https://gcc.gnu.org/gcc-10/porting_to.html). This causes
linking issues when building genisoimage:
```bash
[ 98%] Building C object genisoimage/CMakeFiles/genisoimage.dir/checksum.o
[100%] Linking C executable genisoimage
/usr/bin/ld: CMakeFiles/genisoimage.dir/apple.o:(.bss+0x0): multiple definition of `outfile'; CMakeFiles/genisoimage.dir/genisoimage.o:(.bss+0x0): first defined here
/usr/bin/ld: CMakeFiles/genisoimage.dir/boot.o:(.bss+0x0): multiple definition of `outfile'; CMakeFiles/genisoimage.dir/genisoimage.o:(.bss+0x0): first defined here
/usr/bin/ld: CMakeFiles/genisoimage.dir/desktop.o:(.bss+0x0): multiple definition of `outfile'; CMakeFiles/genisoimage.dir/genisoimage.o:(.bss+0x0): first defined here
/usr/bin/ld: CMakeFiles/genisoimage.dir/dvd_file.o:(.bss+0x0): multiple definition of `outfile'; CMakeFiles/genisoimage.dir/genisoimage.o:(.bss+0x0): first defined here
```
Rather than patching genisoimage further, just pass -fcommon to preserve
the legacy GCC behaviour.
Noticed [while testing #19530](https://github.com/bitcoin/bitcoin/pull/19530#issuecomment-659802512).
ACKs for top commit:
laanwj:
ACK 2a701a1c42
hebasto:
ACK 2a701a1c42, tested on Fedora 32 (x86_64, GCC 10.1.1):
Tree-SHA512: 0e6dd1b4c7c3f5b6997616da27a7ea54f757c81677766ee6813c776356527787a32b959f834e699fee9798553b13bcb142469f442c5e7a04f810f2c06e3a9505
Starting with the 10.1 release, GCC defaults to -fno-common. This causes
linking issues when building genisoimage:
```bash
[ 98%] Building C object genisoimage/CMakeFiles/genisoimage.dir/checksum.o
[100%] Linking C executable genisoimage
/usr/bin/ld: CMakeFiles/genisoimage.dir/apple.o:(.bss+0x0): multiple definition of `outfile'; CMakeFiles/genisoimage.dir/genisoimage.o:(.bss+0x0): first defined here
/usr/bin/ld: CMakeFiles/genisoimage.dir/boot.o:(.bss+0x0): multiple definition of `outfile'; CMakeFiles/genisoimage.dir/genisoimage.o:(.bss+0x0): first defined here
/usr/bin/ld: CMakeFiles/genisoimage.dir/desktop.o:(.bss+0x0): multiple definition of `outfile'; CMakeFiles/genisoimage.dir/genisoimage.o:(.bss+0x0): first defined here
/usr/bin/ld: CMakeFiles/genisoimage.dir/dvd_file.o:(.bss+0x0): multiple definition of `outfile'; CMakeFiles/genisoimage.dir/genisoimage.o:(.bss+0x0): first defined here
```
Rather than patching genisoimage further, pass -fcommon to preserve the
legacy GCC behaviour.
6457361e90 qt: Fix QFileDialog for static builds (Hennadii Stepanov)
Pull request description:
This change partially reverts 248e22bbc0 (#16386) and makes `QFileDialog`s work again for static builds.
Fixes https://github.com/bitcoin-core/gui/issues/32.
ACKs for top commit:
fanquake:
ACK 6457361e90. Although it would be good to know exactly _why_ this fixes the issue. At this stage I also don't think this should be a blocker for 0.20.1.
theuni:
ACK 6457361e90
Tree-SHA512: 8ad27e0bcae6debd02f73b7c374743e37d4edd806922b103a2fe494cf2d9930fe9ef3107b5a6c61f3c466cf7462de2641171880398954e7f2c4f417f5bb820d7
Note that this does not _enable_ lto by default in any way, only hooks up the
machinery for -flto to work correctly.
enable-lto-support is explicitly used for pinned-clang because we know it
works. It is neither enabled nor disabled in the external clang case so that
it can be auto-detected.
For depends builds this was fixed by fbcfcf69, which deleted the conflicting
headers. When we no longer control the clang installation, we need to ensure
that the SDK's libc++ headers are used rather than the ones shipped with clang.
We can do that by turning off the default include path and hard-coding our own.
This hard-coded path is ok because we control (via SDK packaging) where these
headers end-up.
Side-note: Now that this path is hard-coded in depends, we can potentially
package the SDK differently, as the c++ folder can live wherever is most
convenient for us.
This should be caught by the differing clang --version outputs, but because we
haven't yet extracted our pinned clang, the system one is actually used for the
version check. That's not a problem because bumping our pinned clang will
cause a rebuild of everything anyway.
a8d39b8840 doc: explain why passing -mlinker-version is required (fanquake)
Pull request description:
I have been down a 🐇 hole. Closes#19359.
When Clang is compiled, [a check is run](https://github.com/llvm/llvm-project/blob/release/8.x/clang/CMakeLists.txt#L353) to define `HOST_LINK_VERSION` as the output of `$CMAKE_LINKER -v`. Note the this is the version of the linker being used to compile Clang itself.. and this check is only run when compiling Clang for macOS.
In the Clang driver, if `HOST_LINK_VERSION` has been defined, there is some additional runtime functionality. An `-mlinker-version` argument, with the value of `HOST_LINK_VERSION` [will be added to the linker arguments](89de0d8dfb/clang/lib/Driver/Driver.cpp (L382)), if `-mlinker-version` has not been passed in by the user.
This is a bit weird, as by default, you are setting `-mlinker-version` to the version of the linker that was used to build the Clang binary, not the linker which will be used when compiling. The commit which introduced the functionality, 628fcf4e3b, described it as a "hack", that should be replaced. However, that was 10 years ago, and the behaviour is still here.
In the Darwin driver, [a check is done](89de0d8dfb/clang/lib/Driver/ToolChains/Darwin.cpp (L208)) for the `-mlinker-version` argument. If there is no argument, the version will default to `0`. Given the above, this should never happen when using Clang for macOS. A series of comparisons are then performed, to check whether the linker version is modern enough to enable certain features, like [`-demangle`](89de0d8dfb/clang/lib/Driver/ToolChains/Darwin.cpp (L215)).
### What this means
#### macOS
A Clang compiled for macOS, i.e `clang+llvm-8.0.0-x86_64-apple-darwin`, will have `HOST_LINKER_VERSION` set to the version of the linker used to compile Clang itself.
At runtime, `-mlinker-version=HOST_LINKER_VERSION` will be added to the linker args, if `-mlinker-version` wasn't passed in. In the Darwin driver, additional arguments, like `-demangle`, will be added to the linker arguments, because `HOST_LINKER_VERSION` was likely some very modern version of `lld` or `ld64`.
#### Linux (cross compilation in depends)
A Clang compiled for Linux, i.e `clang+llvm-8.0.0-x86_64-linux-gnu-ubuntu-14.04`, which we now use for macOS builds in depends, will behave differently. As it's built for Linux, `HOST_LINKER_VERSION` was not defined at compile time, and there will be no default behaviour of appending `-mlinker-version=HOST_LINKER_VERSION` to the linker args. Thus, unless you pass in `-mlinker-version` yourself, when the version checks are done in the Darwin driver, no modern linker features will be enabled, as the version will have defaulted to `0`.
Therefore, it's important that we continue to pass `-mlinker-version="our LD64 version"` as part of our compilation flags, if we want to have "modern" linker features enabled for our macOS builds.
#### Summary
[Clang 8](https://releases.llvm.org/download.html#8.0.0). Building a macOS binary. Link line with path arguments trimmed.
| | default behaviour | `-mlinker-version=100` (`-demangle threshold`) | `-mlinker-version=530` |
| - | --------------- | --------------------- | ---------------------- |
| macOS Clang | `-demangle -lto_library ../libLTO.dylib -no_deduplicate -dynamic -arch x86_64 -macosx_version_min 10.15.0 -o a.out ../test-b8b9b3.o -lc++ -lSystem ../libclang_rt.osx.a` | `-demangle -dynamic -arch x86_64 -macosx_version_min 10.15.0 -o a.out ../test-a66966.o -lc++ -lSystem ../libclang_rt.osx.a` | same as default |
| Linux Clang | `-dynamic -arch x86_64 -macosx_version_min 10.12.0 -o a.out ../test-bfce57.o -lc++ -lSystem` | `-demangle -dynamic -arch x86_64 -macosx_version_min 10.12.0 -o a.out ../test-a846a3.o -lc++ -lSystem` | `-demangle -lto_library ../libLTO.dylib -no_deduplicate -dynamic -arch x86_64 -macosx_version_min 10.12.0 -o a.out ../test-de0280.o -lc++ -lSystem` |
Note: Most links here are pointing to the 8.x branch of LLVM/Clang, as we are using that version in depends.
Note: To add a little more confusion, you wont see `-mlinker-version X` in your compile flags, you'll see [`-target-linker-version X`](431daedee4/clang/lib/Driver/ToolChains/Clang.cpp (L4777)).
ACKs for top commit:
laanwj:
ACK a8d39b8840
Tree-SHA512: 92f93079a5e59a0d561e74336b5cb03e3bf5a34437f5850283b9128c7624494b8285ec16290b1fa8103fe87f8789a53ce44b17902b8c1db5fde24d74b76fb168
This enables of the use of AI_* definitions in the Windows headers,
specifically AI_ADDRCONFIG, which fixes an issue with libevent and
ipv6 on Windows.
It also aligns with what we define in configure when building Core.
libevent uses getaddrinfo when available, and falls back to gethostbyname
Windows has both, but gethostbyname only supports IPv4
libevent fails to detect Windows's getaddrinfo due to not including the right headers
This patches libevent's configure script to check it correctly
8a26848c46 build: Fix m4 escaping (Hennadii Stepanov)
9123ec15db build: Remove extra tokens warning (Hennadii Stepanov)
fded4f48c3 build: Remove duplicated QT_STATICPLUGIN define (Hennadii Stepanov)
05a93d5d96 build: Fix indentation in bitcoin_qt.m4 (Hennadii Stepanov)
ddbb419310 build: Use pkg-config in BITCOIN_QT_CONFIGURE for all hosts (Hennadii Stepanov)
492971de35 build: Fix mingw pkgconfig file and dependency naming (Hennadii Stepanov)
Pull request description:
This PR makes `bitcoin_qt.m4` to use `pkg-config` for all hosts and removes non-pkg-config paths from it. This is a step towards the idea which was clear [stated](https://github.com/bitcoin/bitcoin/pull/8314#issue-76644643) by Cory Fields:
> I believe the consensus is to treat Windows like the others and require pkg-config across the board. We can drop all of the non-pkg-config paths, and simply AC_REQUIRE(PKG_PROG_PKG_CONFIG)
There are two unsolved problems with this PR. If depends is built with `DEBUG=1` the `configure` script fails to pickup Qt:
- for macOS host (similar to, but not the same as #16391)
- for Windows host (regression)
The fix is ~on its way~ submitted in #18298 (as a followup).
Also this PR picks some small improvements from #17820.
ACKs for top commit:
theuni:
Code review ACK 8a26848c46
dongcarl:
Code Review ACK 8a26848c46
laanwj:
Code review ACK 8a26848c46
Tree-SHA512: 3b25990934b939121983df7707997b31d61063b1207d909f539d69494c7cb85212f353092956d09ecffebb9fef28b869914dd1216a596d102fcb9744bb5487f7
f0d7ed10b4 depends: Propagate only specific CLI variables to sub-makes (Carl Dong)
0a33803f1c depends: boost: Use clang toolset if clang in CXX (Carl Dong)
1ce74bcde3 depends: boost: Split target-os from toolset (Carl Dong)
2d4e480813 depends: boost: Specify toolset to bootstrap.sh (Carl Dong)
3d6603e340 depends: Propagate well-known vars into depends (Carl Dong)
Pull request description:
From: https://github.com/bitcoin/bitcoin/pull/18308#issuecomment-598301117
The following monstrosity is quite useful when invoked inside `depends`, and reviewers can use it to compare the behaviour of this change against master.
```bash
make print-{{,{host,{,{i686,x86_64,riscv64}_}linux}_}{CC,CXX},boost_{cc,cxx}}
```
It would also be helpful to make sure that setting `HOST`, `CC`, and `CXX` does the right thing. The 3 hosts I found offered good coverage were: `{x86_64,i686,riscv64}-linux-gnu`. As we special-case the `x86_64` and `i686` hosts in `depends/hosts/linux.mk`, and `riscv64` is a sanity check for a non-special-cased host.
ACKs for top commit:
hebasto:
ACK f0d7ed10b4, tested on Linux Mint 19.3 (x86_64):
practicalswift:
ACK f0d7ed10b4 -- patch looks correct
laanwj:
Code review and concept ACK f0d7ed10b4
ryanofsky:
Code review ACK f0d7ed10b4. Changes since last review: adding comment explaining check for predefined make variables, dropping freetype commit, adding commit whitelisting overrides for recursive makes
Tree-SHA512: b6b8e76f713c26a0add6cd685824e2f5639109236ee9f89338f7c79cb1b1f2c3897bfb62b80b023d6d1943b5a6eb282a2f827f1f499c5e556eca015d6635fa65
We want to supply well-known vars to ./configure scripts to do with as
they please. However, we do _not_ want to override these well-known vars
at make-time as certain build systems expect a self-mangled version of
these well-known vars.
For example, freetype and bdb will prepend `libtool --mode=compile' to
CC and CXX, which, if we override CC on the command line at make-time,
will break the build.
Previously, we specified the target-os in the toolset (and sometimes
used the wrong command line flags), now we have a clear separation,
which is favored by ./bootstrap.sh and ./b2.
This means that all supported OSes will specify the correct target-os=
and toolset= on the command line.
b2 will pickup our user-config.jam just fine, however, bootstrap.sh has
its own toolset autodetect mechanism, which doesn't GAF about our
user-config.jam
These haven't been updated since their addition, so this updates the list that
controls which qt base translations are bundled with the macOS binary, to all the
languages that are available with qt 5.9.8.
This could probably be improved in some way, however qt updates are infrequent,
and I didn't want to spend any more time looking at this. Also given that no-one
seems to have noticed and/or reported this it wouldn't seem high-priority.
Could be backported to 0.20.1.
Catalina SDK clang stopped automatically searching the SDK include paths when
invoked without --sysroot:
https://github.com/bitcoin/bitcoin/pull/16367#issuecomment-594600985https://github.com/Homebrew/homebrew-core/issues/45061
This hasn't been a problem for current native depends packages because are
passing their own --sysroot values, and hasn't been a problem for current host
packages because they use `darwin_` commands instead of `build_darwin_`
commands. But the current `build_darwin_CC` and `build_darwin_CXX` commands
are still unnecessarily fragile, and incompatible with new native depends
packages added in https://github.com/bitcoin/bitcoin/pull/18677.
Cory Fields <cory-nospam-@coryfields.com> suggested in
https://github.com/bitcoin/bitcoin/pull/16367#issuecomment-595393546 switching
compiler from SDK clang to native clang (from $PATH) to avoid this problem.
This is easy and makes a certain amount of sense for building native packages,
as opposed to host packages. But fanquake <fanquake@gmail.com> pointed out in
https://github.com/bitcoin/bitcoin/pull/18677#discussion_r409934309 that it
would be inconsistent use switch to non-SDK compilers while still using other
SDK tools like ranlib and install_name_tool. So simplest, minimal fix seems to
be just adding the missing --sysroot option.
This change adds to the BITCOIN_QT_CONFIGURE script ability to use
pkg-config for MinGW. All of the non-pkg-config paths are removed as
needless.
If depends is built with DEBUG=1 the configure script fails to pickup
Qt:
- for macOS host (similar, but not the same as issue 16391)
- for Windows host (regression)
This change adds the correct suffix to debug mode .pc filenames for
MinGW and also to the Qt libraries listed in the `Requires` field.
The filename adjustment fixes the accidental overwriting of release
mode .pc files with the debug mode variant which required the wrong
variant of the libraries when `debug_and_release` is active.
Note that macOS also supports the `debug_and_release' configuration
but may use the regular library names together with DYLD_IMAGE_SUFFIX.
Creation of *_debug.pc files is turned off as they're identical to their
non-debug counterparts.
More info:
- QTBUG-4155
- Qt commit a0d8fb4ac3cb7bafdb39f340055eacee4f957513
cb9e88e73a build: don't embed a build-id when building libdmg-hfsplus (fanquake)
Pull request description:
There was a [reproducibility issue (IRC logs)](http://www.erisian.com.au/bitcoin-core-dev/log-2020-01-25.html) with the osx `0.19.1rc1` gitian builds. The `build-id` embedded into the `dmg` tool was mismatching. It's possible that differing versions of binutils/ld were the cause.
While it was resolved after rebuilding the base gitian image, whether an upstream package issue or fluke, we can remove the possibility of it happening in future by just not embedding a build-id into the `dmg` tool at all. Can close if it's not deemed worth it.
You can test this change using the following:
```bash
# build libdmg
make native_libdmg-hfsplus_built -C depends/ HOST=x86_64-apple-darwin16 -j6 V=1
# master
readelf --string-dump .note.gnu.build-id /bitcoin/depends/work/build/x86_64-apple-darwin16/native_libdmg-hfsplus/7ac55ec64c96f7800d9818ce64c79670e7f02b67-3830944ef98/build/dmg/dmg
String dump of section '.note.gnu.build-id':
[ c] GNU
[ 11] CjRa?]?^V8?v?;%n??
# this pr
readelf --string-dump .note.gnu.build-id /bitcoin/depends/work/build/x86_64-apple-darwin16/native_libdmg-hfsplus/7ac55ec64c96f7800d9818ce64c79670e7f02b67-a72f53ab110/build/dmg/dmg
readelf: Warning: Section '.note.gnu.build-id' was not dumped because it does not exist!
```
ACKs for top commit:
laanwj:
tested ACK cb9e88e73a
Tree-SHA512: 191eed32ed0a04a908f9c1b22188180b2db2f35bae0281940f0f9da2450c5c6807cd6ff5bbcce7c933a9133387b127c3478f7a39a2918c14f17be19fd9ea19b4
fae9084ac5 build: Skip i686 build by default in guix and gitian (MarcoFalke)
fa55a2554c depends: Remove reference to win32 (MarcoFalke)
Pull request description:
Closes#17504
Now that we no longer provide downloads for i686 on our website (https://bitcoincore.org/en/download/), there is no need to build them by default.
i686 can still be built in depends (tested by ci/travis) and in guix/gitian by setting the appropriate `HOSTS`.
ACKs for top commit:
practicalswift:
ACK fae9084ac5 -- patch looks correct
dongcarl:
ACK fae9084ac5 patch looks correct
laanwj:
Code review ACK fae9084ac5
hebasto:
ACK fae9084ac5, I have reviewed the code and it looks OK, I agree it can be merged.
Tree-SHA512: b000c19a2cd2a596a52028fa298c4022c24cfdfc1bdb3795a90916d0a00a32e4dd22278db93790b6a11724e08ea8451f4f05c77bc40d1664518e11a8c82d6e29
0e519fe284 build: Fix behavior when ALLOW_HOST_PACKAGES unset (Hennadii Stepanov)
Pull request description:
On master (f05c1ac444) during building with depends host packages are always considered by `pkg-config` regardless of `ALLOW_HOST_PACKAGES` environment variable. This causes issues like #18042.
This is an alternative to #18042 and #18045.
On master:
```
$ make HOST=x86_64-apple-darwin16 -C depends
$ CONFIG_SITE=$PWD/depends/x86_64-apple-darwin16/share/config.site ./configure
...
checking for QT_DBUS... yes
...
checking whether to build GUI with support for D-Bus... yes
...
```
---
With this PR:
1) `ALLOW_HOST_PACKAGES` unset
```
$ make HOST=x86_64-apple-darwin16 -C depends
$ CONFIG_SITE=$PWD/depends/x86_64-apple-darwin16/share/config.site ./configure
...
checking for QT_DBUS... no
...
checking whether to build GUI with support for D-Bus... no
...
```
2) `ALLOW_HOST_PACKAGES=1`
```
$ make HOST=x86_64-apple-darwin16 ALLOW_HOST_PACKAGES=1 -C depends
$ CONFIG_SITE=$PWD/depends/x86_64-apple-darwin16/share/config.site ./configure
...
checking for QT_DBUS... yes
...
checking whether to build GUI with support for D-Bus... yes
...
```
ACKs for top commit:
jonasschnelli:
Tested ACK 0e519fe284 - After this PR (and after a `make clean` & `make HOST=x86_64-apple-darwin16` in depends), the macOS depends build on a Debian machine with qt as host package worked (it fails on master due to `ENABLE_DBUS=1`).
Tree-SHA512: d11e1c2bc8ce8a07f3f9b465b01c9b2c814afe75b085a8b88aab74fd3a922aa98180c447457dfc4174515513181c5f4edc521978a1d3d0a112106c98b5c73c0e
All other mk files use the package variable consistently except for the two instances here, which have always been here, since depends was introduced in 0.10.
e97f5c1823 depends: don't configure xcb_proto (fanquake)
Pull request description:
xcb_proto's configure doesn't understand `--disable-shared` or
`--with-pic`. All the package does it put a stack of XML files into
a directory to be used by libxcb.
Probably enough to close#16354.
ACKs for top commit:
dongcarl:
ACK e97f5c1823
Tree-SHA512: 1a49fd7c8269405bbf312be33c1aeaac5f25ef8666829b01dc3c58f3a2a9281c23c42614a7f1cfc3ee260be4ea3e71285869b1cb9c2035dceda336296d9d9dea
11113247c3 depends: Support for S390X targets (MarcoFalke)
989fd539d5 depends: Support for 64-bit POWER targets (Luke Dashjr)
Pull request description:
Failure before:
```
$ make -C depends HOST=powerpc64-linux-gnu
...
ERROR: Feature 'system-zlib' was enabled, but the pre-condition 'libs.zlib' failed.
ERROR: Feature 'xcb' was enabled, but the pre-condition 'libs.xcb' failed.
ERROR: Feature 'system-freetype' was enabled, but the pre-condition 'features.freetype && libs.freetype' failed.
ERROR: Feature 'fontconfig' was enabled, but the pre-condition '!config.win32 && !config.darwin && features.system-freetype && libs.fontconfig' failed.
make: *** [funcs.mk:254: /bitcoin/depends/work/build/powerpc64-linux-gnu/qt/5.9.8-95548079095/qtbase/.stamp_configured] Error 3
$ make -C depends HOST=s390x-linux-gnu
...
ERROR: Feature 'system-zlib' was enabled, but the pre-condition 'libs.zlib' failed.
ERROR: Feature 'xcb' was enabled, but the pre-condition 'libs.xcb' failed.
ERROR: Feature 'system-freetype' was enabled, but the pre-condition 'features.freetype && libs.freetype' failed.
ERROR: Feature 'fontconfig' was enabled, but the pre-condition '!config.win32 && !config.darwin && features.system-freetype && libs.fontconfig' failed.
make: *** [funcs.mk:254: /bitcoin/depends/work/build/s390x-linux-gnu/qt/5.9.8-79c6d6ca6ec/qtbase/.stamp_configured] Error 3
```
ACKs for top commit:
laanwj:
Code review ACK 11113247c3
dongcarl:
tested ACK 11113247c3
practicalswift:
ACK 11113247c3 -- diff looks correct
Tree-SHA512: f990101ced0ed579168bb25762c1296c9b512c597bab924013af41832670a69ed786c6ec9b654c95fe064187797880a66c575395bc102a914c1bdb323ca7538a
2359a4790d depends: don't use OpenGL in Qt on macOS (fanquake)
ba0cad2702 build: pass -dead_strip_dylibs to ld on macOS (fanquake)
Pull request description:
Based on #17663. OpenGL on macOS was also deprecated in 10.14.
This also removes the `/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL` dylib from `bitcoin-qt`.
ACKs for top commit:
laanwj:
ACK 2359a4790d
jonasschnelli:
utACK 2359a4790d
hebasto:
ACK 2359a4790d
Tree-SHA512: 39b0151832c829f6ebdc4910eb28ebbeba64539cd04eba6ce3ec75fc0f231569956ca51a1e0bffc76dd27e85643c65a155320b9b450c49e9841e12b108406d41
xcb_proto's configure doesn't understand --disable-shared or
--with-pic. All the package does it put a stack of xml files into
a directory to be used by libxcb.
6fdf5dab26 depends: only use dbus with qt on linux (fanquake)
Pull request description:
Since #8210 we've been passing `-dbus-runtime` when configuring Qt, however D-Bus isn't used on macOS or Windows. So rather than blanket passing `-dbus-runtime`, only use D-Bus when building for linux, and disable it for Windows and macOS. This also saves some time building qt in depends (for windows or macOS).
This gist contains a diff of the symbols in a macOS bitcoin-qt after applying this change: https://gist.github.com/fanquake/317e5c9c7d1b5e37a0c1ce8001af18c4.
ACKs for top commit:
laanwj:
ACK 6fdf5dab26
Tree-SHA512: 7c7df6036f27dae6adb807edf94cd26b4dafa3728976d219a68f7388b6477777b35acebd507320e4469c9f2fcf016b311c82e0b12d50546cb5ab66a1e955e464
02ac445b2f bump libevent to 2.1.11 in depends (stefanwouldgo)
Pull request description:
this doesn't need patches on Android anymore like 2.1.8 did.
ACKs for top commit:
laanwj:
ACK 02ac445b2f
Tree-SHA512: 1fbfe342ee15fa4c5cb417979bd6c443f7c7aa40a489accf8ccd7c919e5b08e859b3da6edeee3de484f6f156b35dd4e97c7e2c7971b59fc31029865585ccb296
f9af3ced1c Android: add all arch support (Block Mechanic)
d419ca7e32 depends: export dynamic JNI symbols from static qtforandroid.a (Igor Cota)
ed30684d03 Qt: patch androidjnimain.cpp to make sure JNI is initialised when statically compiled (Igor Cota)
e4c319e8a1 builds: remove superfluous config_opts_aarch64_android (Igor Cota)
24ffef0c27 Patch libevent when building for Android (fix arc4random_addrandom) (Igor Cota)
f1e40b3e71 Update bitcoin_qt.m4 (BlockMechanic)
b4057d8261 Define TARGET_OS when host is android (Igor Cota)
80b475f159 Fix Android zlib cross compilation issue (https://stackoverflow.com/questions/21396988/zlib-build-not-configuring-properly-with-cross-compiler-ignores-ar) (Igor Cota)
45f8219015 Add full Android build example command and instructions on getting SDK/NDK (Igor Cota)
b68f2a68c2 Add config opts and patch for aarch64_android build of Qt (Igor Cota)
9c4cb0166e Add ranlib to android.mk hosts file (fix OSX Android NDK build) (Igor Cota)
c2a749c9c1 Add example Android host-platform-triplet and options (Igor Cota)
0b0cff3c61 Add support for building Android dependencies (Igor Cota)
Pull request description:
This allows one to build the dependencies with the Android SDK and goes towards fixing #11844. It has been tested to work with:
`make HOST=aarch64-linux-android ANDROID_API_LEVEL=28 ANDROID_TOOLCHAIN_BIN=/home/user/Android/Sdk/ndk-bundle/toolchains/llvm/prebuilt/linux-x86_64/bin NO_QT=1 NO_WALLET=1`
ACKs for top commit:
Sjors:
ACK f9af3ce. I'm OK with merging and then improving later.
Tree-SHA512: cb805115ebe5c9e33db2bf3eab8628808fe3f50052053d8877d8b8e4406d6fea1ed9e5c4dff85d777fb99c81be6ffb9d95a0e6d32344e728e5e0da6c653e2ce7
8c6081a884 compat: remove bswap_* check on macOS (fanquake)
2cba35ab38 build: skip building OpenSSL lib_ssl (fanquake)
45a2d3c552 build: remove OpenSSL from Qt build (fanquake)
befbc40eb5 build: remove EVP_MD_CTX_new detection (fanquake)
fcee10c2d0 build: remove SSL lib detection (fanquake)
c7f30dbca8 gui: Update BIP70 support message (fanquake)
a3e810326d build: remove BIP70 entries from macOS Info.plist (fanquake)
72fe13a58d gui: remove payment request file handling from OpenURI dialog (fanquake)
3548e4aac7 Remove BIP70 Support (fanquake)
1cb9a4e28c docs: remove protobuf from docs (fanquake)
67328bb7ca build: remove protobuf from depends (fanquake)
Pull request description:
This removes [BIP70](https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki) support. It also removes OpenSSL linking from Qt and building OpenSSLs `lib_ssl` in depends, as well as SSL lib detection from the build system. It's something that I'd optimistically like to do for `0.20.0`.
ACKs for top commit:
laanwj:
Code review ACK 8c6081a884
MarcoFalke:
ACK 8c6081a884
fjahr:
ACK 8c6081a
Tree-SHA512: 9dd9153afa4eca1a795f983e5b31f5fee9fa9a064c2a95d2f98810689add3ad0bf221c4608282299e66e4d1ec31cd556d4b16eea55de7912c3b9931f64735883
The ancient "darwin-4.9.1" profile has long been used to match against
clang, which prior to version 9, reported 4.9.1 as its version when
invoking "clang++ -dumpversion". Presumably this was a historical
compatibility quirk related to Apple's switch from gcc to clang.
This was "fixed" in clang 9.0, so that -dumpversion reports the real
version. Unfortunately that had the side-effect of breaking the
(brittle) boost compiler detection.
Move to the seemingly more-correct "clang-darwin" profile, which passes
the checks and builds correctly.
Also switch to using ar rather than libtool for archiving, as it's what
the clang-darwin profile expects to be using.
Note that because this is using a different profile, some of the final
command-line arguments end up changing. The changes look sane at a
glance.
1ba49bcdc2 build: pass --enable-option-checking to applicable packages (fanquake)
bcff8e21b1 build: only pass --disable-dependency-tracking to packages that understand it (fanquake)
Pull request description:
By blanket passing `--disable-dependency-tracking` to all depends packages we end up with warnings (i.e in `bdb` or `freetype`) like:
```bash
configure: WARNING: unrecognized options: --disable-dependency-tracking
```
Instead, only pass it to packages that actually understand it. Related to https://github.com/bitcoin/bitcoin/issues/16354.
More info on `--disable-dependency-tracking` available [here](https://www.gnu.org/software/automake/manual/html_node/Dependency-Tracking.html).
This PR also adds `--enable-option-checking` as a configure option to all applicable packages.
ACKs for top commit:
laanwj:
ACK 1ba49bcdc2
theuni:
ACK 1ba49bcdc2
Tree-SHA512: 6d3143ad5f5d1abed5e0a0b2ffbb4323f21c7bf24b0b8df26fb1b3cd16cf5309bbb830aa5aaec99164d5bbe8e9c62b97aa3e97ee1ddc2c7612bf8ff88a63885e
a0daea459c [build] depends macOS: point --sysroot to SDK (Sjors Provoost)
Pull request description:
Fixes errors like `fatal error: 'unistd.h' file not found` when building depends on macOS.
Replaces #14352 (which doesn't work on Catalina).
ACKs for top commit:
jonasschnelli:
utACK a0daea459c
Tree-SHA512: 995b1e1e84e635b32d1d4038bc63730c94a7c318b7240f6d62825977e5c97fe52c5aa5a0f39070beb0df8271dd294b36d6b5cf7f09ad07494fb15d5bd4d77f68
By blanket passing --disable-dependency-tracking to all depends packages
we end up with some warnings like:
configure: WARNING: unrecognized options: --disable-dependency-tracking
So instead, only pass it to packages that understand it.
Related to https://github.com/bitcoin/bitcoin/issues/16354.
463a1d5244 Refresh ZeroMQ 4.3.1 patch (Nathan Marley)
Pull request description:
Currently in Alpine Linux (latest, 3.10) in the depends system, one of the ZeroMQ patches won't apply cleanly because the context around the patch has changed and Alpine's `patch` implementation can't handle the diff.
Some patch implementations can't handle fuzz / too much divergence from the original code.
This PR just tweaks the context code around the patch so that less-sophisticated patch implementations (such as on Alpine Linux) can apply the patch without errors.
This partially fixes#16925
ACKs for top commit:
fanquake:
ACK 463a1d5244 - Tested building zeromq in depends inside an [Alpine container](https://github.com/fanquake/core-review/blob/master/docker/alpine.dockerfile) as well as on macOS.
Tree-SHA512: d6e3cb60835cdd090b9b864ca9cb33961687606bc9184fbbeb7a54ec23db4057b9317b65c5c276fb8c5492cb3cfcc4a7f3369f049551f4eb0915db971f2290ce
568aa0cf83 Add OpenSSL termios fix for musl libc (Nathan Marley)
Pull request description:
Currently the version of OpenSSL included in the depends system won't build on musl based systems because `termio.h` does not exist. The proper header named `termios.h` does exist.
This PR adds a patch for OpenSSL to replace the `termio.h` header with `termios.h`, which is the proper POSIX header as I understand it.
This is a known issue as `TERMIOS` (not `TERMIO`) should be the default, and is fixed in later versions of OpenSSL. There is discussion on the OpenSSL repo here: openssl/openssl#163
This has been [fixed in OpenSSL](64e6bf64b3).
This partly fixes#16925 and allows building Bitcoin on Alpine using the depends system.
ACKs for top commit:
laanwj:
ACK 568aa0cf83
Tree-SHA512: d0aac116b7a1133bdecb34a9fb6c63db0336a3547585c07ed31ac9c5edb97e9570dcbf931e7fbc7172ce0735b6bfc11fb204e015532fcd90496a233e8fc17081
Some patch implementations can't handle fuzz / too much divergence from the
original code.
This just tweaks the context code around the patch so that less-sophisticated
patch implementations (such as on Alpine Linux) can apply the patch without
errors.
f0636d3418 depends: zlib: Move toolchain options to configure (Carl Dong)
Pull request description:
```
zlib has its own custom configure script, see comment in zlib.mk for
more details
```
Performed Guix cross-builds locally and everything worked as expected.
ACKs for top commit:
laanwj:
ACK f0636d3418
Tree-SHA512: 7ff6114e52a9c49941da31cb0ebd8918b056bf23343790d758e107003d856f3b1f16ebf4ce0ce22e1216a37a610b4c106def3f869d128bfffa61280d45ed6b38
QMAKE_LFLAGS was removed from qtbase/mkspecs/win32-g++/qmake.conf in
39fc377bf105ba09e2a8f9acae467dc789b96525. Here, we add it back in with
our LDFLAGS from depends before the first occurance of any
QMAKE_LFLAGS_* variable settings.
0c6054fc9f depends: Bump QT to LTS release 5.9.8 (THETCR)
Pull request description:
This update is only a minor version but in contrary to 5.9.7 it's a LTS release.
It doesn't add any new functionality to Qt but fixes multiple security issues and bugs.
Including some race conditions and annoying bugs on macOS.
ACKs for top commit:
Sjors:
ACK 0c6054fc9f. Lightly tested on macOS 10.14.6. Not really sure what difference would matter on macOS.
Tree-SHA512: f01d947cc0db6d761e32551071fa00fe8014fb7b2ce707271a159bb61c6d60e062ac8f4da5f36bd8fc4736e1e852368a1353ea3f994f61f1d0c76cc7d1664938
c295cba5a2 depends: zeromq: disable draft classes and methods (fanquake)
0072237b9e depends: xproto: configure flags cleanup (fanquake)
6a8ada3a4f depends: qrencode: configure flags cleanup (fanquake)
86beb8cdc4 depends: fontconfig: configure flags cleanup (fanquake)
e656d95ec7 depends: libxcb: configure flags cleanup (fanquake)
e439388b35 depends: libXau: configure flags cleanup (fanquake)
Pull request description:
Related to #16354.
This PR adds additional configure flags to packages in depends to explicitly disable features we aren't using; similar to #16183. It also fixes passing `--without-tools` to `qrencode`.
I've added `--disable-drafts` to `zeromq`:
```bash
Build and install draft classes and methods [default=yes]
```
I'm not entirely sure how far we want to take this. i.e in the `zeromq` package we explicitly pass `--without-libsodium`, even though it's disabled by default.
Do we also want to explicitly pass all the other `--without` flags? :
```bash
--with-libgssapi_krb5 require libzmq build with libgssapi_krb5
[default=no]
--with-libsodium use libsodium instead of built-in tweetnacl
[default=no]
--with-pgm build libzmq with PGM extension. Requires pkg-config
[default=no]
--with-norm build libzmq with NORM protocol extension,
optionally specifying norm path [default=no]
--with-vmci build libzmq with VMCI transport [default=no]
```
ACKs for top commit:
dongcarl:
ACK c295cba5a2
Tree-SHA512: df6d38b863b4008ed2cb06c97eb0e21eaa4b5fde552876065ba7f3c87bf6e372e5b954a51bf3fde2151cfb6d2c022227d34337fc6e50ce0caa1d518abbd2412a
Because we pass -qt-xcb to Qt, it will compile in a set of xcb helper libraries and extensions.
So skip building all of the libxcb extensions when we build libcxb in depends.
More info is available here: https://doc.qt.io/qt-5.9/linux-requirements.html
f509e3b8ce doc: remove line numbers from qt package links (fanquake)
1bb1661a40 doc: fix typo in bitcoin_qt.m4 comment (fanquake)
0aeb98ac1f build: remove jpeg lib check from bitcoin_qt.m4 (fanquake)
98a64bd296 build: disable libjpeg in qt (fanquake)
Pull request description:
When gitian building on Windows I'm seeing:
```bash
checking for Qt 5... yes
checking for > Qt 5.7... yes
checking for main in -limm32... yes
checking for main in -lz ... yes
checking for library containing jpeg_create_decompress ... configure: WARNING: libjpeg not found. Assuming qt has it built-in
no
checking for library containing png_error ... -lqtlibpng
checking for library containing pcre2_match_16... -lqtpcre2
checking for library containing hb_ot_tags_from_script ... -lqtharfbuzz
```
We are passing `-qt-libjpeg` to Qt:
e6e99d4f75/depends/packages/qt.mk (L66)
but I dont think we are doing anything with `jpeg` related regardless?
ACKs for top commit:
laanwj:
ACK f509e3b8ce
promag:
ACK f509e3b8ce.
Tree-SHA512: 61ea20c11df11b9d426644df9a01aac12b76897003121a283fc784a8c30e9b5ad34c9805069fec20926f7aa279e59528e2e13697a944a22760c3acb6366fffbe
libXext was only needed (as a library) by QT when it was using
XLib/libX11 (as a library), now that we're building QT without
XLib/libX11, we can safely remove libXext.
We're no longer building QT with libX11/XLib, however, libX11/XLib
headers are still required for parts of QT. In this commit we add a
minimal configure.ac for libX11/XLib that is headers-only.
This change allows us to remove all of libX11/XLib's dependencies.
Previously, in 683b7d7a3f and
0e752637a2, we accidentally broke QT's
ability to pick up Xlib thru the config.gui.tests.xlib configuration
test, which also means that config.gui.libraries.xcb_xlib wasn't run.
This resulted in a QT build that was implicitly -no-xcb-lib and
-no-feature-xlib.
This is actually a desired behaviour, as it means less required shared
objects for our final bitcoin-qt binary. Specifically, it eliminated the
libX11-xcb.so.1 and libX11.so.6 requirements.
In this commit, we explicitly build without Xlib. We should continue to
track upstream ticket https://bugreports.qt.io/browse/QTBUG-61452 which
talks about adding a -no-xlib (non-hidden) flag instead of the
-no-feature-xlib (hidden) flag.
63d0a079e0 build: dont compile rapidcheck with -Wall (fanquake)
Pull request description:
Fixes#16062.
Remove `-Wall` from the rapidcheck build flags pre compilation.
Discussed briefly with theuni.
ACKs for top commit:
MarcoFalke:
ACK 63d0a079e0 (checked that `RAPIDCHECK=1 make rapidcheck` fails without this)
Tree-SHA512: 6cb3653221c1eadbc8da54812298a061130b4377da6f63dcc2dfb97379d303b4db538e67f4fe3c96a03ee6a1e65840f0def0ac4e862553480c7ac4bdcc77e113
xtrans does not understand the --with-pic and --disable-shared flags we
pass it because it is not a library. Instead, we should pass it flags
that disable features/packages we're not using so they don't get a
chance to sneak in.
2620e24b83 [depends] boost: update to 1.70 (Sjors Provoost)
Pull request description:
Version [1.70](https://www.boost.org/users/history/version_1_70_0.html) is most recent.
Versions needed for:
* 1.66: #12557: fixes the single arm64 configuration ([06ee5b5](06ee5b54ef))
ACKs for commit 2620e2:
Tree-SHA512: 6e0174f1d92c2c24314c0689d4809e048914f8f42d17aa73799f5ee232169e0dd0ed71f5f973903c44c08309f2837c629c493f15e5c31ec6c7bd1daae5f3b25f
8541cbea2 depends: libX*: --disable-malloc0returnsnull in conf (Carl Dong)
0e752637a depends: libXext: Bump to 1.3.3 to fix _XEatDataWords (Carl Dong)
683b7d7a3 depends: Purge libtool archives (Carl Dong)
14209286d depends: Build secondary deps statically. (Carl Dong)
Pull request description:
```
We use pkg-config where we can, which generally replaces libtool at a
higher level and does not have the same downsides as libtool. These
archives sit in our depends tree with no purpose and pollute the final
bitcoin build with massive overlinking.
```
See [here](https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Handling_Libtool_Archives) for an explanation of the various problems libtool archives can cause.
Unrelated in every way except in spirit: `-D__LIBTOOL_IS_A_FOOL__`!!
-----
This PR is based on #16041, and therefore should be merged after #16041.
ACKs for commit 8541cb:
Tree-SHA512: 76030cf32361f0b1cfe14e3827a0cbec99994e7da00a56194ca40cf6cf7d87f78552f49d03d41ce9cf9b642992b90d993578ed1f0ad6bae15cd3f1c88dfaa4b0
We use pkg-config where we can, which generally replaces libtool at a
higher level and does not have the same downsides as libtool. These
archives sit in our depends tree with no purpose and pollute the final
bitcoin build with massive overlinking.
d8bc47fde4 depends: switch to secure download of all dependencies (Ulrich Kempken)
Pull request description:
Even if we potentially check the integrity of the downloaded file via hash comparison, we should make use of SSL since it is available.
ACKs for commit d8bc47:
jonasschnelli:
utACK d8bc47fde4
practicalswift:
utACK d8bc47fde4
dongcarl:
tACK d8bc47fde4
Tree-SHA512: e47702f6d243ed7f498ca84c193244382f16f08df6a297caa224b4468f501f3da6fe542fcf3a0dd9c24ab1b0b38bbc51478068e6006a92854ded23abf90de3c8
Some dependency sources were downloaded via http, even though https (SSL/TLS) options are available.
Even if we potentially check the integrity of the downloaded files via hash comparison, we should make
use of this additional security layer.
bdb.mk
fontconfig.mk
freetype.mk
libX11.mk
libXau.mk
libXext.mk
libxcb.mk
native_cctools.mk
native_cdrkit.mk
xcb_proto.mk
xextproto.mk
xproto.mk
xtrans.mk
zlib.mk
miniupnp was switched to official project mirror with SSL support
6d44c5ebf9 depends: Add commands for each package for each stage (Carl Dong)
80f0e05b70 depends: Preprocessing doesn't care about deps (Carl Dong)
Pull request description:
Adds make targets for each package for each stage, e.g.
```sh
make zeromq_configured
```
ACKs for commit 6d44c5:
MarcoFalke:
ACK 6d44c5ebf9 (Haven't looked at the code changes, but adding this feature makes sense)
ryanofsky:
ACK 6d44c5ebf9
Tree-SHA512: f1ac0aecfd2372aed09ca63603e2634552cb3f6ff9d610f958e2a66952d7d9e870b4c32b7d996886879e6d3016532272e8b1a10c13ed7b31009c6c96f786db9f
For normal users, --no-same-owner is default, but not so for root, where
it is assumed that root can change ownership willy-nilly. This is not
the case for privilege-limited container environments where we gaslight
the process into thinking it's root.
5bb0164cee depends: Enable unicode support on dbd for Windows (Chun Kuan Lee)
Pull request description:
define `UNICODE` and `_UNICODE` while compiling for Windows. This would make dbd read filename as utf8 string.
Tree-SHA512: 58ee86ca5333c416c7c4db8266887c085c486cabfbb68c6bd0e66519abb3abfedac6bb7d28e4228eb5c2c4436e4e5060eb7b22490044143b6676d23fc627540a
f149e31ea2 depends: qt: avoid system harfbuzz and bz2 (Cory Fields)
Pull request description:
Should fix#14367.
Gitian builds end up with this config implicitly due to missing harfbuzz system lib, this change explicitly disables the use of the lib completely, even if present.
We may eventually want to break out harfbuzz and build it in depends, but for now just ensure that runtime dependencies don't depend on whether or not harfbuzz was present on the builder.
@real-or-random Can you confirm that this fixes your issue?
Tree-SHA512: 1ad3dd572c1f2004ec80ebaf3b6831327b0267fb3dc1895e77bd04785cd6e32bafc931932195462bbae807289bc565f0ea740f4050d26f0233ddcd62bfdb0685
fad95e8da6 doc: Split build linux dependencies (MarcoFalke)
0000009015 doc: Split depends installation instructions per arch (MarcoFalke)
Pull request description:
The current depends installation instructions fail on bionic with
```
E: Unable to locate package g++-4.8-aarch64-linux-gnu
E: Unable to locate package gcc-4.8-aarch64-linux-gnu
E: Unable to locate package g++-4.8-arm-linux-gnueabihf
E: Unable to locate package gcc-4.8-arm-linux-gnueabihf
```
Also, they fail due to missing dependencies `make automake cmake pkg-config python3`
Fix this by removing the explicit version and splitting them into common instructions and instructions per linux architecture.
Tree-SHA512: 25d5efa7450a0b1bbd569f431158f5a25bf4fe34f6adc32ebdfd6b6db9447ce083f555f20ff5b9f7c458864986c15d65219a31a1cd2b18bad9965ece2ea5e3be
We may eventually want to break out harfbuzz and build it in depends, but
for now just ensure that runtime dependencies don't depend on whether or not
harfbuzz was present on the builder.
A few years ago, libfreetype introduced FT_Get_Font_Format() as an alias for
FT_Get_X11_Font_Format(), but FT_Get_X11_Font_Format() was kept for abi
backwards-compatibility.
Our qt bump to 5.9 introduced a call to FT_Get_Font_Format(). Replace it with
FT_Get_X11_Font_Format() in order to remain compatibile with older freetype,
which is still used by e.g. Ubuntu Trusty.
e7a72455fa Scripts and tools: increased timeout downloading (Emanuele Cisbani)
Pull request description:
DOWNLOAD_CONNECT_TIMEOUT changed from 10 to 30 because some file start only after 15 sec (see below).
```
Fetching boost_1_64_0.tar.bz2 from https://dl.bintray.com/boostorg/release/1.64.0/source/
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- 0:00:15 --:--:-- 0
100 76.7M 100 76.7M 0 0 1863k 0 0:00:42 0:00:42 --:--:-- 8136k
/home/gitianuser/bitcoin/depends/work/download/boost-1_64_0/boost_1_64_0.tar.bz2.temp: OK
```
Tree-SHA512: 43250df818eacedeed5fa3cc8453ecedbf564776fa1c6124e872f46d123423f8bdf174a47389dce7d6cc6b96791953b1bb2f96ce3df6c156415f0c3de2d5cc76
DOWNLOAD_CONNECT_TIMEOUT changed from 10 to 30 because some file start only after 15 sec (see below).
Fetching boost_1_64_0.tar.bz2 from https://dl.bintray.com/boostorg/release/1.64.0/source/
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- 0:00:15 --:--:-- 0
100 76.7M 100 76.7M 0 0 1863k 0 0:00:42 0:00:42 --:--:-- 8136k
/home/gitianuser/bitcoin/depends/work/download/boost-1_64_0/boost_1_64_0.tar.bz2.temp: OK
update copyright headers
attempt to fix linting errors
Fixing issue with make check classifying generator files as actual unit tests
Wrapping gen files in ENABLE_PROPERTY_TESTS macro
Make macro better
Qt's configure grabs the path to xkb's data root during configure, but the
build changes in 5.8 apparently broke the handling for cross builds. As a
result, the string embedded in the binary depends on whether or not some files
are present in the builder's filesystem.
The "-xkb-config-root" configure setting is intended to allow manual overriding
but it is also broken. See: https://bugreports.qt.io/browse/QTBUG-60005
This has since been fixed upstream, so just hard-code the path for now. We can
drop this patch when we bump to a fixed Qt.
Also, fix the "-qt-xkbcommon-x11" config param which was renamed. This does not
appear to affect build results, presumably because auto-detection is working,
but it does not hurt to be explicit.
6b5506a286 Fix Qt's rcc determinism for depends/gitian (Fuzzbawls)
Pull request description:
With the update to Qt 5.9 having been merged, Qt's `rcc` tool now embeds a file's last modified time in it's output. Since the build system generates temporary files for all locale translations (`*.qm` files) at build time, the resulting `qrc_bitcoin_locale.cpp` file was always being generated in a non-deterministic way.
This is a backport of https://bugreports.qt.io/browse/QTBUG-62511, which is included in Qt versions 5.11+, that allows for an environment variable (`QT_RCC_SOURCE_DATE_OVERRIDE`) to override the behavior described above. This environment variable is in turn set in the gitian descriptors, as that is where determinism is vital for release purposes.
Prior to this, the `qt_libbitcoinqt_a-qrc_bitcoin_locale.o` object file (included into `libbitcoinqt.a`) was returning a different `sha256sum` for each and every build, regardless of file contents change, thus breaking determinism in the resulting binaries.
This should fix#13731
Tree-SHA512: 174017e41f9afc3950ef54a9419de81577ec900db9aec3c78ccd3d879c6aecaaeb944fde0615b933f43e6ca9d7898a27ec071cdd0b91cb772755a3012de96725
12c93cb85b depends: use MacOS friendly sed syntax in qt.mk (Sjors Provoost)
Pull request description:
I just got this error on master:
```
make clean-all
make -j5
[...]
/bitcoin/depends/sources/qttools-opensource-src-5.9.6.tar.xz: OK
Preprocessing qt...
sed: 1: "qtbase/mkspecs/bitcoin- ...": extra characters at the end of q command
make: *** /bitcoin/depends/work/build/x86_64-apple-darwin17.7.0/qt/5.9.6-b48df1b490b/.stamp_preprocessed] Error 1
```
Tree-SHA512: 1eaee535c0d637a67801c7dd48e9cd5a037823f4e162a6f50e375787045fdb95929f409a88c7d000d8781a4edc497b5ccb1fd23a24e29324ec633157fadd371e
f447a0a707 Remove program options from build system (Chun Kuan Lee)
11588c639e Replace boost program_options (Chun Kuan Lee)
Pull request description:
Concept from #12744, but without parsing negated options.
Tree-SHA512: 7f418744bb8934e313d77a5f162633746ef5d043de802b9c9cd9f7c1842e7e566eb5f171cd9e2cc13317281b2449c6fbd553fa4f09b837e6af2f5d2b2aabdca2
4b69984557 Add depends 32-bit arm support for bitcoin-qt (Sebastian Kung)
Pull request description:
Some hobbyists are used to using the desktop for interfacing with their raspberry pi. This commits adds qt to the arm-linux-gnueabihf target.
Tree-SHA512: cb03387267eb8f68dfd79735c2c01c5a119c406e5578805e60b377934da42d46cb34d35e45c8843979dfb4070859c553d09ae348b468d9731523f33307132fa8
974f0bf8e6 depends: Mention RISC-V known compilation issue with gcc-7.3.x (Wladimir J. van der Laan)
0d1f38c45f depends: update zmq config.guess/config.sub for riscv support (fanquake)
409481c465 depends: latest config.sub (fanquake)
d7005e9988 depends: latest config.guess (fanquake)
359e2e3525 depends: Add RISC-V support (Wladimir J. van der Laan)
Pull request description:
This adds support for riscv32 and riscv64 builds to the depends system.
The change consists of documentation and build system changes. The most significant change is an update of `config.sub` and `config.guess` inside zeromq patch, as the current version does not recognize the `riscv*` host tuples (there's no new version of ZeroMQ yet with newer ones).
Good thing: RISC-V 64-bit toolchain packages can be installed out of the box on Ubuntu 18.04+.
I would also like to add RISC-V 64-bit executables to gitian, but this will not be possible until #12511 .
Tree-SHA512: 358ed72ee9e4ae44e7d305c09a4ff5ce5460eeb7ed915eb25d39c8f43b61e7b347f51bf0ae5d83ddb4ce8876dea7703c926b3baa3cccb4932b3bc17160d801bb
aff16fd depends: Add 'make clean' and 'make clean-all' rules (Henrik Jonsson)
Pull request description:
It's useful to have a standard way to clean up the work done by the
depends system when testing changes to it.
Tree-SHA512: d56686ca810c2531d852049420f242178d124d45a2508feeac0acf80408e8a95fc9915fb777ff0cbc4edc496990f5fdecf699c87d7986164c74b8fbf418ebf49
It's useful to have a standard way to clean up the work done by the
depends system when testing changes to it.
The `make clean-all` rule removes build artifacts for all
supported architectures (in addition to sources/), while `make clean`
only removes artifacts for current architecture (`BUILD`).
4ef82f1 depends: biplist 1.0.3 (fanquake)
Pull request description:
biplist should now be usable for reproducible builds without any patching.
One change has been incorporated, the two remaining changes were rejected upstream: https://bitbucket.org/wooster/biplist/pull-requests/9/make-biplist-ordering-deterministic/diff#comment-None
testing on gitian cc @jonasschnelli
Tree-SHA512: a3ef3ecad08b09f7a34d927bc4e3d8604099e9acb2c984bbe741df6162f4014f40e9eb2fd28309fc79d3dd2bb82f14bfd473925b90048e5fd135a471726a4836
cc879675e1 depends: Remove ccache (fanquake)
Pull request description:
After discussion with @theuni, we can possibly just remove ccache from depends entirely.
Related to #12606
Tree-SHA512: ae0a60c8d97467fa41d617daa48ed22159cf32613808634a983304901dd5ed27124e77868d2314004e5144f7b35ba1333f720bb12daec4c5ca03aaf29d593ef2
The patch Bitcoin Core has been maintaining for mac_alias was pulled by the mac_alias maintainer in commit 4f31cb084c1c6a8626128b0b00842020b6db9037. Delete the patch and remove the patch from the depends system.
Note that this PR won't be complete until a new version of mac_alias containing the path has been released, and the depends system is updated to reflect the new version.
31a013563 Add required package dependencies for depends cross compilation [skip-ci] (Jonas Schnelli)
Pull request description:
Stumbled over this during a setup of a new depends compile system.
Related to #8913.
Tree-SHA512: 67e2fdf9ca3cbedeb02982fa73771dd36978b319e9291ea5a41ede7fdf772c4505ccc9523b48fe66ead927f141efefbdf1e3eaa19a9d8a1304861a8ede040056
This is broken for a number of reasons, including:
- g++ understands "-static-libstdc++ -lstdc++" to mean "link against whatever
libstdc++ exists, probably shared", which in itself is buggy.
- another stdlib (libc++ for example) may be in use
4f92b5f Run Qt wallet tests on travis (Russell Yanofsky)
Pull request description:
Currently these test failures are not caught by travis leading to bugs like:
https://github.com/bitcoin/bitcoin/pull/10506
Tree-SHA512: db1e4ff5b17bcd6fd000a3d21aa74f6b7e4c194e0663c1896a100612671910a7cdadd896b59642420ea016598895b54a8468914847ebefef105a3c47c311d4b2
ld64 is threaded, and uses a worker for each CPU to parse input files. But
there's a bug in the parser causing dependencies to be calculated differently
based on which files have already been parsed.
As a result, builders with more CPUs are more likely to see non-determinism.
This looks to have been fixed in a newer version of ld64, so just disable
threading for now. There's no noticible slowdown.
This contains a few hacks very specific to Qt's buildsystem. These can be
reverted once we split the build between native and target builds.
Qt's build contains a circular dependency when not using a system zlib.
By far the easiest fix is to switch to a system zlib, rather than Qt's own.
However, that confuses Qt's cross build which assumes that when using a system
zlib, it should also find a system (native) zlib for native tools. The build
breaks if that zlib is not present.
To solve this:
1. Always use a system zlib rather than the one provided by qt
2. Set force_bootstrap, which instructs the build tools to be built as though
we're cross-compiling (build != target)
3. For build tools, use qt's internal zlib so that a native zlib is not
required.
Step 3 means that if any zlib headers are found by the native build, it will
confuse Qt's internal zlib build. So we also need to make sure that the target
headers/libs aren't found. To do so, specify that our
cflags/cxxflags/cppflags/ldflags only apply for non-host builds.
qt5.7 changed the location of some of its symbols, creating a circular
dependency in Qt5Core. Rather than trying to fix that up, build our own zlib
rather than having it built for us.
Their buildsystem insists on using the installed ltranslate, but gets confused
about how to find it. Since we manually control the build order, just drop the
dependency.
Add a patch that seems to be necessary for compatibilty of libevent
2.0.22 with recent mingw-w64 gcc versions (at least GCC 5.3.1 from Ubuntu
16.04).
Without this patch the Content-Length in the HTTP header ends up as
`Content-Length: zu`, causing communication between the RPC
client and server to break down. See discussion in #8653.
Source: https://sourceforge.net/p/levent/bugs/363/
Thanks to @sstone for the suggestion.
- create a script to handle split debug. This will also eventually need to check
targets, and use dsymutil for osx.
- update config.guess/config.sub for bdb for aarch64.
- temporarily disable symbol checks for arm/aarch64
- quit renaming to linux32/linux64 and use the host directly
This also adds a hack to work around an Ubuntu bug in the gcc-multilib package:
https://bugs.launchpad.net/ubuntu/+source/gcc-defaults-armhf-cross/+bug/1347820
The problem is that gcc-multilib conflicts with the aarch toolchain.
gcc-multilib installs a symlink that points
/usr/include/asm -> /usr/include/x86_64-linux-gnu/asm.
Without this link, gcc -m32 can't find asm/errno.h (and others), since
/usr/include/x86_64-linux-gnu isn't in its default include path. But
/usr/include/i386-linux-gnu is (though it doesn't exist on disk).
So work around the problem by linking
/usr/include/i386-linux-gnu/asm -> /usr/include/x86_64-linux-gnu/asm.
The symlink fix is actually quite reasonable, but echoing the password into
sudo is nasty, and should probably be addressed in gitian itself. It makes more
sense to enable passwordless sudo for the build user by default.
7e7eb27 gitian: create debug packages for linux/windows (Cory Fields)
ad38204 gitian: use CONFIG_SITE rather than hijacking the prefix (Cory Fields)
b676f38 depends: allow for CONFIG_SITE to be used rather than stealing prefix (Cory Fields)
This does not break any existing prefix behavior, only makes new behavior work.
For example:
CONFIG_SITE=$PWD/depends/x86_64-pc-linux-gnu/share/config.site ./configure --prefix=/
These add very simple sanity checks to ensure that the build/host toolchains
have not changed since the last run. If they have, all ids will change and
packages will be rebuilt.
For more complicated usage (like parsing dpkg), HOST_ID_SALT/BUILD_ID_SALT may
be used to introduce arbitrary data to the ids.
2016/01/24:
Change miniwget to return HTTP status code
Increments API_VERSION to 16
2016/01/22:
Improve UPNPIGD_IsConnected() to check if WAN address is not private.
Parse HTTP response status line in miniwget.c
