aboutsummaryrefslogtreecommitdiff
path: root/depends/packages/boost.mk
AgeCommit message (Collapse)Author
2021-05-09build: build Boost with -fcf-protection when targeting Darwinfanquake
The LLVM Clang we use for cross-compilation supports this option, and it's expected that any builders on macOS will also be using an Apple Clang that supports it.
2021-04-12build,boost: update download url.fdov
- bintray is closing. - updated to jfrog.io.
2021-02-02build: don't build or use Boost Threadfanquake
2020-11-30Merge #20471: build: use C++17 in dependsfanquake
2f5dfe4a7ff12b6b57427374142cdf7e266b73bc depends: build qt in c++17 mode (fanquake) 104e859c9755aee5708ea1934454d88b10c266ff builds: don't pass -silent to qt when building in debug mode (fanquake) e2c500636cb767347ae2b913345788ad3c3e8279 depends: build zeromq with -std=c++17 (fanquake) 2374f2fbef4359476fe3184e2402a2cc741cefad depends: build Boost with -std=c++17 (fanquake) 2dde55702da30ea568cac8a1d1cbddd652d6958e depends: build bdb with -std=c++17 (fanquake) Pull request description: In packages where we are passing `-std=c++11` switch to `-std=c++17`, or, `-std=c++1z` in the case of Qt. This PR also contains a [commit](https://github.com/bitcoin/bitcoin/commit/104e859c9755aee5708ea1934454d88b10c266ff) that improves debug output when building Qt for debugging (`DEBUG=1`). Now we'll get output like this: ```bash g++ -c -pipe -ffunction-sections -O2 -fPIC -std=c++11 -fno-exceptions <lots more> ../../corelib/kernel/qcoreapplication.cpp ``` rather than just: ```bash compiling ../../corelib/kernel/qcoreapplication.cpp ``` Note that when you look at the DEBUG output for these changes when building Qt, you'll see objects being compiled with a mix of C++11 and C++17. The breakdown is roughly: 1. `qmake` built with `-std=c++11`: ```bash Creating qmake... make[1]: Entering directory '<trim>/qt/5.9.8-4110fa99945/qtbase/qmake' g++ -c -o project.o -std=c++11 -ffunction-sections -O2 -g <trim> <trim>/qt/5.9.8-4110fa99945/qtbase/qmake/project.cpp # when qmake, Qt also builds some of it's corelib, such as corelib/global/qmalloc.cpp g++ -c -o qmalloc.o -std=c++11 -ffunction-sections -O2 -g <trim> <trim>/qt/5.9.8-4110fa99945/qtbase/src/corelib/global/qmalloc.cpp ``` 2. `qmake` is run, and passed our build options, including `-c++std`: ```bash make[1]: Entering directory '<trim>/qt/5.9.8-4110fa99945/qtbase' <trim>qt/5.9.8-4110fa99945/qtbase/bin/qmake -o Makefile qtbase.pro -- -bindir <trim>/native/bin -c++std c++1z -confirm-license <trim> ``` 3. After some cleaning and configuring, we actually start to build Qt, as well as it's tools and internal libs: ```bash Building qt... make[1]: Entering directory '<trim>/qt/5.9.8-4110fa99945/qtbase/src' # build libpng, zlib etc gcc -c -m64 -pipe -pipe -O1 <trim> -o .obj/png.o png.c # build libQt5Bootstrap, using C++11, which again compiles qmalloc.cpp make[2]: Entering directory '<trim>/qt/5.9.8-4110fa99945/qtbase/src/tools/bootstrap' g++ -c -pipe -ffunction-sections -O2 -fPIC -std=c++11 <trim> -o .obj/qmalloc.o ../../corelib/global/qmalloc.cpp # build a bunch of tools like moc, rcc, uic, qfloat16-tables, qdbuscpp2xml, using C++11 g++ -c -pipe -O2 -std=c++11 -fno-exceptions -Wall -W <trim> -o .obj/rcc.o rcc.cpp # from here, Qt is compiled with -std=c++1z, including qmalloc.cpp, for the third and final time: g++ -c -include .pch/Qt5Core <trim> -g -Og -fPIC -std=c++1z -fvisibility=hidden <trim> -o .obj/qmalloc.o global/qmalloc.cpp ``` 4. Finally, build tools like `lrelease`, `lupdate`, etc, but back to using -std=c++11 ```bash make[1]: Entering directory '<trim>/qt/5.9.8-4110fa99945/qttools/src/linguist/lrelease' g++ -c -pipe -O2 -std=c++11 -fno-exceptions -Wall -W <trim> -o .obj/translator.o ../shared/translator.cpp ``` If you dump the debug info from the built Qt libs, they should also tell you that they were compiled with `C++17`: ```bash objdump -g bitcoin/depends/x86_64-pc-linux-gnu/lib/libQt5Core.a GNU C++17 9.3.0 -m64 -mtune=generic -march=x86-64 -g -O1 -Og -std=c++17 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -fasynchronous-unwind-tables -fstack-protector-strong -fstack-clash-protection -fcf-protection ``` ACKs for top commit: laanwj: Code review ACK https://github.com/bitcoin/bitcoin/pull/20471/commits/2f5dfe4a7ff12b6b57427374142cdf7e266b73bc practicalswift: cr ACK 2f5dfe4a7ff12b6b57427374142cdf7e266b73bc: patch looks correct fjahr: Code review ACK 2f5dfe4a7ff12b6b57427374142cdf7e266b73bc hebasto: ACK 2f5dfe4a7ff12b6b57427374142cdf7e266b73bc, I have reviewed the code and it looks OK, I agree it can be merged. Tree-SHA512: fc5e9d7c7518c68349c8228fb1aead829850373efc960c9b8c079096a83d1dad19c62a9730fce5802322bf07e320960fd47851420d429eda0a87c307f4e8b03a
2020-11-24depends: build Boost with -std=c++17fanquake
2020-11-23depends: boost: Specify cflags+compileflagsCarl Dong
2020-11-23depends: boost: Remove unnecessary _archiver_Carl Dong
We already have $(package)_ar, so just use that instead
2020-11-23depends: boost: Cleanup toolset selectionCarl Dong
2020-11-23depends: boost: Cleanup architecture/address-modelCarl Dong
2020-11-23depends: boost: Disable all compressionCarl Dong
2020-11-23depends: boost: Split into non-/native packagesCarl Dong
2020-11-23depends: boost: Bump to 1.71.0Carl Dong
2020-11-23depends: boost: Refer to version in URLCarl Dong
2020-08-25build: use patch rather than sed in Boost packagefanquake
The depends comment is actually incorrect, and this can be dropped once we move to 1.71.0 or later.
2020-07-31[depends] boost: patch unused variable in boost_processSjors Provoost
Co-Authored-By: fanquake <fanquake@gmail.com>
2020-05-27depends: boost: Use clang toolset if clang in CXXCarl Dong
2020-05-27depends: boost: Split target-os from toolsetCarl Dong
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.
2020-05-27depends: boost: Specify toolset to bootstrap.shCarl Dong
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
2020-05-12depends: add MULTIPROCESS depends optionRussell Yanofsky
Builds required packages and passes --enable-multiprocess option to bitcoin build
2020-04-10Revert "Merge #16367: Multiprocess build support"MarcoFalke
This reverts the changes made in merge commit 1b307613604883daea4913a65da30ae073c9dc4d: This reverts commit b919efadff3d0393f4a8c3c1dc735f7ac5c665bb. This reverts commit d54f64c6c700be0604190f52c84fc5f1cdd9f02f. This reverts commit 787f40668dc15980c3d6de028d7950c08175d84a. This reverts commit d6306466626635e6fee44385e6a688c8dc118eb5. This reverts commit e6e44eedd56ecaf59f3fabf8e07ab7dee0ddb1b6.
2020-04-05libmultiprocess depends buildRussell Yanofsky
2020-03-07build: remove chrono package from depends Boostfanquake
2020-01-16depends: Consistent use of package variablePeter Bushnell
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.
2019-11-04Merge #16110: depends: Add Android NDK supportWladimir J. van der Laan
f9af3ced1c69d65c5c530ec5526f5eefaf786126 Android: add all arch support (Block Mechanic) d419ca7e32bfc71e8dd1f1b91870463eacd6ad8e depends: export dynamic JNI symbols from static qtforandroid.a (Igor Cota) ed30684d03d3a1d5496e69c488d848fe92ae6fb4 Qt: patch androidjnimain.cpp to make sure JNI is initialised when statically compiled (Igor Cota) e4c319e8a1c6e40a953036b942bd5d732b0bbf69 builds: remove superfluous config_opts_aarch64_android (Igor Cota) 24ffef0c271739a2ca75feecb816f3218c1850bf Patch libevent when building for Android (fix arc4random_addrandom) (Igor Cota) f1e40b3e7114b18bc03f45c3a97f9f673543ddef Update bitcoin_qt.m4 (BlockMechanic) b4057d82618a21720f39f448b689cebf475cc2dc Define TARGET_OS when host is android (Igor Cota) 80b475f159525737e242161397f35d0729449545 Fix Android zlib cross compilation issue (https://stackoverflow.com/questions/21396988/zlib-build-not-configuring-properly-with-cross-compiler-ignores-ar) (Igor Cota) 45f82190150b3feef333724ea7395ba080e700b1 Add full Android build example command and instructions on getting SDK/NDK (Igor Cota) b68f2a68c211aa2264e9ca824d10a90f4a5a5af4 Add config opts and patch for aarch64_android build of Qt (Igor Cota) 9c4cb0166e801471f8cb3d82656c86bacf051db6 Add ranlib to android.mk hosts file (fix OSX Android NDK build) (Igor Cota) c2a749c9c16697e744ecfb283fdf4095d0278066 Add example Android host-platform-triplet and options (Igor Cota) 0b0cff3c61610fb56f8c5c9451ace01598117a8d 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
2019-10-23depends: fix boost mac cross build with clang 9+Cory Fields
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.
2019-10-18Android: add all arch supportBlock Mechanic
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
2019-05-03[depends] boost: update to 1.70Sjors Provoost
2018-07-18Remove program options from build systemChun Kuan Lee
2017-05-03[depends] Boost 1.64.0fanquake
2017-01-11[depends] Boost 1.63.0fanquake
2016-09-27[depends] Boost 1.61.0fanquake
2016-04-27depends: use c++11Cory Fields
2015-11-10[depends] Boost 1.59.0fanquake
2015-07-03depends: bump boost to 1.58.0Cory Fields
2015-06-13depends: fix Boost 1.55 build on GCC 5Jacob Welsh
Boost assumes variadic templates are always available in GCC 4.4+, but they aren't since we don't build with -std=c++11. This applies the patch that fixed the issue in boost 1.57: https://github.com/boostorg/config/commit/eec808554936ae068b23df07ab54d4dc6302a695 See also: https://svn.boost.org/trac/boost/ticket/10500
2014-11-19depends: Use pic for all linux dependenciesCory Fields
This avoids textrels, and matches previous gitian behavior.
2014-11-05depends: boost: hard-code hidden symbol visibilityCory Fields
tl;dr: This solves boost visibility problems for default/release build configs on non-Linux platforms. When Bitcoin builds against boost's header-only classes, it ends up with objects containing symbols that the upstream boost libs also have. Since Bitcoin builds by default with hidden symbol visibility, it can end up trying to link against a copy of the same symbols with default visibility. This is not a problem on Linux because 3rd party static libs are un-exported by default (--exclude-libs,ALL), but that is not available for MinGW and OSX. Those platforms (and maybe others?) end up confused about which version to use. The OSX linker spews hundreds of: "ld: warning: direct access in <foo> to global weak symbol guard variable for <bar> means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings." MinGW's linker complains similarly. Since the default symbol visibility for Bitcoin is hidden and releases are built that way as well, build Boost with hidden visibility. Linux builds Boost this way also, but only for the sake of continuity. This means that the linker confusion logic is reversed, so the problem will will now be encountered if Bitcoin is built with --disable-reduce-exports, but that's better than the current situation.
2014-09-25depends: boost: build for debug or release as requestedCory Fields
Also hook up cppflags there, which was missing before.
2014-08-08depends: add shared dependency builderCory Fields
See the README's in depends for documentation