Age | Commit message (Collapse) | Author |
|
ff4a38a32766942ce5c4be6d6510f800a9f8e0d9 build: Fix configuring depends with cmake (Hennadii Stepanov)
Pull request description:
This PR fixes bitcoin/bitcoin#24389.
On master (28aa0e3ca0a6cfeb5b2b63929d4bc58de6ee6f02) configuring of the `libmultiprocess` package for the `x86_64-w64-mingw32` target fails:
```
$ cd depends
$ make libmultiprocess_configured MULTIPROCESS=1 HOST=x86_64-w64-mingw32
Configuring libmultiprocess...
CMake Warning:
No source or binary directory provided. Both will be assumed to be the
same as the current working directory, but note that this warning will
become a fatal error in future CMake releases.
-- The CXX compiler identification is GNU 9.3.0
-- Check for working CXX compiler: /usr/bin/x86_64-w64-mingw32-g++-posix
-- Check for working CXX compiler: /usr/bin/x86_64-w64-mingw32-g++-posix -- broken
CMake Error at /usr/share/cmake-3.16/Modules/CMakeTestCXXCompiler.cmake:53 (message):
The C++ compiler
"/usr/bin/x86_64-w64-mingw32-g++-posix"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: /home/hebasto/GitHub/bitcoin/depends/work/build/x86_64-w64-mingw32/libmultiprocess/d576d975debdc9090bd2582f83f49c76c0061698-f496b1e64cb/CMakeFiles/CMakeTmp
Run Build Command(s):/usr/bin/make cmTC_93273/fast && make[1]: Entering directory '/home/hebasto/GitHub/bitcoin/depends/work/build/x86_64-w64-mingw32/libmultiprocess/d576d975debdc9090bd2582f83f49c76c0061698-f496b1e64cb/CMakeFiles/CMakeTmp'
/usr/bin/make -f CMakeFiles/cmTC_93273.dir/build.make CMakeFiles/cmTC_93273.dir/build
make[2]: Entering directory '/home/hebasto/GitHub/bitcoin/depends/work/build/x86_64-w64-mingw32/libmultiprocess/d576d975debdc9090bd2582f83f49c76c0061698-f496b1e64cb/CMakeFiles/CMakeTmp'
Building CXX object CMakeFiles/cmTC_93273.dir/testCXXCompiler.cxx.o
/usr/bin/x86_64-w64-mingw32-g++-posix -I/home/hebasto/GitHub/bitcoin/depends/x86_64-w64-mingw32/include -pipe -O2 -o CMakeFiles/cmTC_93273.dir/testCXXCompiler.cxx.o -c /home/hebasto/GitHub/bitcoin/depends/work/build/x86_64-w64-mingw32/libmultiprocess/d576d975debdc9090bd2582f83f49c76c0061698-f496b1e64cb/CMakeFiles/CMakeTmp/testCXXCompiler.cxx
Linking CXX executable cmTC_93273
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_93273.dir/link.txt --verbose=1
/usr/bin/x86_64-w64-mingw32-g++-posix -I/home/hebasto/GitHub/bitcoin/depends/x86_64-w64-mingw32/include -pipe -O2 -L/home/hebasto/GitHub/bitcoin/depends/x86_64-w64-mingw32/lib -rdynamic CMakeFiles/cmTC_93273.dir/testCXXCompiler.cxx.o -o cmTC_93273
x86_64-w64-mingw32-g++-posix: error: unrecognized command line option ‘-rdynamic’
make[2]: *** [CMakeFiles/cmTC_93273.dir/build.make:87: cmTC_93273] Error 1
make[2]: Leaving directory '/home/hebasto/GitHub/bitcoin/depends/work/build/x86_64-w64-mingw32/libmultiprocess/d576d975debdc9090bd2582f83f49c76c0061698-f496b1e64cb/CMakeFiles/CMakeTmp'
make[1]: *** [Makefile:121: cmTC_93273/fast] Error 2
make[1]: Leaving directory '/home/hebasto/GitHub/bitcoin/depends/work/build/x86_64-w64-mingw32/libmultiprocess/d576d975debdc9090bd2582f83f49c76c0061698-f496b1e64cb/CMakeFiles/CMakeTmp'
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:6 (project)
-- Configuring incomplete, errors occurred!
See also "/home/hebasto/GitHub/bitcoin/depends/work/build/x86_64-w64-mingw32/libmultiprocess/d576d975debdc9090bd2582f83f49c76c0061698-f496b1e64cb/CMakeFiles/CMakeOutput.log".
See also "/home/hebasto/GitHub/bitcoin/depends/work/build/x86_64-w64-mingw32/libmultiprocess/d576d975debdc9090bd2582f83f49c76c0061698-f496b1e64cb/CMakeFiles/CMakeError.log".
make: *** [funcs.mk:283: /home/hebasto/GitHub/bitcoin/depends/work/build/x86_64-w64-mingw32/libmultiprocess/d576d975debdc9090bd2582f83f49c76c0061698-f496b1e64cb/./.stamp_configured] Error 1
```
The reason of that failure is the unset `-DCMAKE_SYSTEM_NAME` flag:
```
$ make print-libmultiprocess_cmake MULTIPROCESS=1 HOST=x86_64-w64-mingw32
libmultiprocess_cmake=env CC="x86_64-w64-mingw32-gcc" CFLAGS=" -I/home/hebasto/GitHub/bitcoin/depends/x86_64-w64-mingw32/include -pipe -O2 " CXX="x86_64-w64-mingw32-g++-posix" CXXFLAGS=" -I/home/hebasto/GitHub/bitcoin/depends/x86_64-w64-mingw32/include -pipe -O2 " LDFLAGS=" -L/home/hebasto/GitHub/bitcoin/depends/x86_64-w64-mingw32/lib " cmake -DCMAKE_INSTALL_PREFIX:PATH="/home/hebasto/GitHub/bitcoin/depends/x86_64-w64-mingw32" -DCMAKE_SYSTEM_NAME= -DCMAKE_C_COMPILER_TARGET=x86_64-w64-mingw32 -DCMAKE_CXX_COMPILER_TARGET=x86_64-w64-mingw32
```
This PR fixes this error:
```
$ make libmultiprocess_configured MULTIPROCESS=1 HOST=x86_64-w64-mingw32
$ # no errors
```
ACKs for top commit:
fanquake:
ACK ff4a38a32766942ce5c4be6d6510f800a9f8e0d9 - going to merge this now, and we can follow up with more cmake improvements.
Tree-SHA512: bd8d8b2f4eedcc8c46cf995b9c39493ea4d0b13c224f77ef62985304ebd392f05119043a06f1401c64f962007a8faa4bb53715d99a408ee6c33bb49a2dd650ba
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|