Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
ae9175f6086aa6c177084365c795e78c580eac1d build: add FreeBSD support to depends (fanquake)
Pull request description:
Setup to use the system Clang (11.0.1 as of FreeBSD 13.0).
Doesn't build the Qt package; that requires a few additional changes. The current issue is that FreeBSDs `byacc` seems to have an issue parsing something in libxkbcommon. Work in progress branch here: https://github.com/fanquake/bitcoin/tree/depends_support_freebsd_qt. In any case, I don't think building the Qt libs on FreeBSD is a super high priority (I'd also have no way to test the GUI).
ACKs for top commit:
laanwj:
ACK ae9175f6086aa6c177084365c795e78c580eac1d
Tree-SHA512: 1ecc7855f0195f68c96e534bd77ce17c3975db1dfb3caa35302c2b46643c8c30f75b1c2e1735cf69f1eddb70447d11e67e7f339ef5497336cdff7a59b32be961
|
|
This change made in a way that is compatible with GNU Make versions
older than 4.3.
|
|
This should be sufficient to support building for Apple ARM when
cross-compiling.
|
|
|
|
host
2fda0c785188ae94fba921c1b8f6f2c005faf1d4 doc: Drop no longer required notes for Windows builds (Hennadii Stepanov)
f09ed92be132ebcb91b459c87d640a14b4b54336 build: Try posix-specific CXX first for mingw32 host (Hennadii Stepanov)
Pull request description:
On master (1186910b6b7ba7c7e5193c76f33f25825e6cc0b7), when cross-compiling for Windows using our depends build system, we must manually choose the POSIX thread model for the `x86_64-w64-mingw32-g++` compiler.
This PR improves the build system to make this choice automa**g**ically.
ACKs for top commit:
jarolrod:
re-ACK 2fda0c785188ae94fba921c1b8f6f2c005faf1d4
shaavan:
tACK 2fda0c785188ae94fba921c1b8f6f2c005faf1d4
Tree-SHA512: ad3bbdfe84b3c8eb56e102aa0abdc76fd864b2724ac59c9a12a798c57d1c5a1172682172588019d5d1715801a9f201fd9424effbd858e8dc30607c23c0d5941f
|
|
GNU Binutils with the exception of the assembler were removed in NDK r23
LTS.
|
|
This is required to use std::filesystem on macOS as support for it only
landed in the libc++ dylib shipped with 10.15.
See also: https://developer.apple.com/documentation/xcode-release-notes/xcode-11-release-notes
Clang now supports the C++17 <filesystem> library for iOS 13, macOS 10.15, watchOS 6, and tvOS 13.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
See previous commit for description.
|
|
Instead of doing the awkward /bin path prepending at config.site
creation time, set darwin_{CC,CXX} in a way that fully determines the
program's path (clang/clang++) similar to how AC_PATH_{TOOL,PROG} would
do.
Also see the added comment block in depends/Makefile for more context on
determining $PATH for our config.site.
|
|
clang warns when a command line option is unused, and some of our tests
use Werror, so unfortunately we cannot use this flag to pin our linker
for now. Leaving this commit in for future reference, as it would be
great if there's more granularity to Werror and we can be explicit about
what linker we want to use.
|
|
|
|
|
|
|
|
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.
|
|
|
|
For now they remain the same, but in the next commit, we will assign
them differently according to wether or not we're using system clang.
|
|
|
|
Without this clang fails to add any newly-added linker features.
Removing this in ca5055a5aa07aba81a87cf12f6f0526a63c423b5 was likely a
regression.
See https://github.com/bitcoin/bitcoin/pull/19240#issuecomment-647764049
for more discussion.
|
|
This gets us a newer SDK with c++17 support and retains 10.12
back-compat.
Co-authored-by: Carl Dong <contact@carldong.me>
|
|
|
|
For example, doing:
make CC=clang CXX=clang++
Should now propagate these settings down to depends packages
|
|
Builds required packages and passes --enable-multiprocess option to bitcoin build
|
|
Co-Authored-By: Carl Dong <accounts@carldong.me>
|
|
This also removes the obsolete mlinker-version option
Co-Authored-By: Cory Fields <cory-nospam-@coryfields.com>
|
|
|
|
Add support for armv7a, i686 and x86_64 archs to android.mk
Add -fPIC to depends file as anddroid requires it see https://stackoverflow.com/questions/30498776/position-independent-executables-and-android
|
|
|
|
|
|
|
|
|
|
|
|
clang: 3.7.1
cctools: 877.8
ld64: 253.9
|
|
|
|
|
|
tl;dr: Update to the newer stable toolchain and SDK for OSX without giving up
any backwards compatibility. We can move to clang 3.5 as a next step which
allows use to use libc++ and the 10.10 sdk, but we'll need to find a build that
works in gitian/travis first.
Switch to a new, better maintained fork of cctools:
https://github.com/tpoechtrager/cctools-port
I've forked this and will be working on it some as well:
https://github.com/theuni/cctools-port
This brings in:
cctools v862
ld64: v241.9
It also fixes 64bit builds, so there's no longer any need to use a 32bit clang.
Since clang is no longer tied to an old/crusty 32bit build, clang has been
upgraded to 3.3. Unfortunately, there's a bug in 3.4 that breaks builds. 3.5
works fine, but there are no binary builds compatible with precise, which is
currently used for gitian and travis. We could always build our own if
necessary.
After updating to stable clang/linker/cctools, it's possible to use a more
recent SDK. The current SDK (10.7) through the most recent 10.10 have all been
built/tested successfully, both with and without 10.6 compatibility. However,
10.10 requires clang 3.5.
SDKs >= 10.9 use libc++ rather than libstdc++. This is verified working as well.
|
|
Linux and mingw enable libstdc++ debugging for extra runtime checks. OSX
doesn't play nice, so don't enable it there.
|
|
|
|
See the README's in depends for documentation
|