49a92579c705831c7ffbcfb24cdf17a94e9a11a0 build: latest config.sub in depends (fanquake)
ced0435a718ddda1451fb49af03bef07ca25b333 build: latest config.guess in depends (fanquake)
Pull request description:
Before we make any local modifications (i.e #28733) pull the latest files from upstream.
ACKs for top commit:
TheCharlatan:
ACK 49a92579c705831c7ffbcfb24cdf17a94e9a11a0
Tree-SHA512: fbbe0d6ef72a196a652467af0550b38da23b932fe68da4965a9b0dc4795db9c869969db98f660cd360f6af3a7659b46c25e3fd398e0ef127dae71726b9a915a6
3333f14efac815ba3c885398a6795c7e8ce68d08 depends: Bump to capnproto-c++-1.0.1 (MarcoFalke)
Pull request description:
Reasons:
* Debian is starting to ship this version in Trixie (https://packages.debian.org/trixie/capnproto), which will likely become the version shipped with Ubuntu 24.04 LTS. So testing with this version will help to find any issues before real users start to use those distro packages.
* The feature is currently experimental, so bumping the version shouldn't cause any production issues.
* With multiprocess begin a priority project for 27.0, it seems better to do build system changes/bumps early, rather than later, to allow for more time testing them.
ACKs for top commit:
TheCharlatan:
Re-ACK 3333f14efac815ba3c885398a6795c7e8ce68d08
fanquake:
ACK 3333f14efac815ba3c885398a6795c7e8ce68d08 - the response from upstream is that [if we submit a PR, they can take a look](https://github.com/capnproto/capnproto/issues/1833#issuecomment-1792582206), so if anyone would like this to work for Windows, I'd suggest sending a patch.
ryanofsky:
Code review ACK 3333f14efac815ba3c885398a6795c7e8ce68d08
Tree-SHA512: 7d53ad1536f042ab43dbc7847126b826e7fc76694f173c348b835fd1067b8f3dd682c5bcb4887f09ee85bab69130721cd7f8fb96b2e82053d4e28bd5c38bdc5f
b5790c35f7e1d48c79b83bded36f3f72c18c9fc1 build: remove dmg dependencies (fanquake)
33ae0bd1e4756ca0f180ac4b3c32c9eb83b88cfd macdeploy: remove DMG generation from deploy script (fanquake)
a128111c29ba0c31763ccbcd316268bfa9c029cd build: produce a .zip for macOS distribution (Hennadii Stepanov)
c38561d6b1de954b712a92cb8a198ed42d73caea build: add -zip option to macdeployqtplus (fanquake)
Pull request description:
It is https://github.com/bitcoin/bitcoin/pull/27099 revived with addressed [comments](https://github.com/bitcoin/bitcoin/pull/27099#issuecomment-1708705686).
From https://github.com/bitcoin/bitcoin/pull/27099#issue-1584429885:
> Reviving the discussion around using a `.zip` for the distributed macOS binaries, as opposed to a `.dmg`.
>
> Given we only had a single report of the "no finder window" issue (#26176), I wonder if that means macOS users were able to figure it out, they gave up/didn't report, or, we just have very few macOS users.
>
> Related to #18128.
That's how it looks on macOS:
ACKs for top commit:
Sjors:
tACK b5790c35f7e1d48c79b83bded36f3f72c18c9fc1
jarolrod:
ACK b5790c35f7e1d48c79b83bded36f3f72c18c9fc1
TheCharlatan:
utACK b5790c35f7e1d48c79b83bded36f3f72c18c9fc1
Tree-SHA512: 6e9cb3ab0f60f8a92bfec50577e8d096c5b23ec09ebbb334826415609140ddc96d470aea37379495c1c6bb1beec0d306b09460f62e1543bb0f4396c10a1dfbe2
`_LIBCPP_ENABLE_ASSERTIONS` is deprecated, and will be removed. [See (from libc++ __config in main)](b57df9fe9a/libcxx/include/__config (L205-L209)):
> TODO(hardening): remove this in LLVM 19.
> This is for backward compatibility -- make enabling `_LIBCPP_ENABLE_ASSERTIONS` (which predates hardening modes)
> equivalent to setting the safe mode.
> ifdef _LIBCPP_ENABLE_ASSERTIONS
> warning "_LIBCPP_ENABLE_ASSERTIONS is deprecated, please use _LIBCPP_ENABLE_SAFE_MODE instead."
From LLVM 17, `_LIBCPP_ENABLE_DEBUG_MODE` can be used instead.
See https://libcxx.llvm.org/Hardening.html.
Related to #28476.
Patch in suport for using -no_fixup_chains, with ld64. This option just
seems to be missing from our version, as it exists in later releases.
This is needed so we can disable fixup_chains in our security checks.
Unfortunately clang 10 does not understand "-mmacosx-version-min=11.0",
as it expects to see only 10.x.
Bump minimally to 11.1 to fix that problem. This will likely be our last
binary toolchain bump, as it will soon be replaced with usage of upstream
vanilla llvm.
Use of -stdlib++-isystem gets rid of any system c++ header include paths and
negates the need for this option. In newer versions of clangs the combo
produces a warning.
4a3f1db4ea5f90277cf7f57c051a2285e8b42468 depends: latest config.sub (fanquake)
ac462c58f999ef1b9cd7d22c699dd189d3bb1e63 depends: latest config.guess (fanquake)
Pull request description:
Been a few years since we last updated these.
Also related to https://github.com/bitcoin/bitcoin/pull/26422#issuecomment-1421178967.
ACKs for top commit:
TheCharlatan:
ACK 4a3f1db4ea5f90277cf7f57c051a2285e8b42468
hebasto:
ACK 4a3f1db4ea5f90277cf7f57c051a2285e8b42468, I've got zero diff with files from the [upstream](https://git.savannah.gnu.org/gitweb/?p=config.git;a=tree).
Tree-SHA512: 8f1af0813c56289c796a6e74965632dd6fa6dd135409250b2d5ebf7c1c2bfb4001195d35e5d7ecc0cad2a049468193b9fefc2b26beb7669afe6bba4d9c3ffa33
This will allow us to use the existing machinery for filtering by
arch, os, debug/release, etc.
For example, the following becomes possible for libevent:
$(package)_config_opts_release=-DEVENT__DISABLE_DEBUG_MODE
Now the define is only set when not building depends with DEBUG=1
It was deprecated in LLVM 15, turned into a compile-time error in LLVM 16:
```bash
In file included from /usr/lib/llvm-16/bin/../include/c++/v1/cassert:19:
/usr/lib/llvm-16/bin/../include/c++/v1/__assert:22:5: error: "Defining _LIBCPP_DEBUG is not supported anymore.
Please use _LIBCPP_ENABLE_DEBUG_MODE instead."
^
1 error generated.
```
and has been removed entirely in LLVM 17 (main),
ff573a42cd.
Building libc++ in debug mode, will also automatically set
`_LIBCPP_ENABLE_DEBUG_MODE` (the new define), so adding it to depends
doesn't seem useful, and would just result in redefinition errors.
I'm wondering if as a followup, we could enable a DEBUG build of libc++
in our MSAN CI job?
Somewhat related to https://github.com/google/oss-fuzz/pull/9828, where
it looks like we'll have to sort out getting a DEBUG build of LLVM.
Compiling bdb with clang-16 on aarch64 (hardware) currently fails:
```bash
make -C depends/ bdb CC=clang CXX=clang++
...
checking for mutexes... UNIX/fcntl
configure: WARNING: NO SHARED LATCH IMPLEMENTATION FOUND FOR THIS PLATFORM.
configure: error: Unable to find a mutex implementation
```
Looking at config.log we've got:
```bash
configure:18704: checking for mutexes
configure:18815: clang -o conftest -pipe -std=c11 -O2 -Wno-error=implicit-function-declaration -Wno-error=format-security -I/bitcoin/depends/aarch64-unknown-linux-gnu/include -D_GNU_SOURCE -D_REENTRANT -L/bitcoin/depends/aarch64-unknown-linux-gnu/lib conftest.c -lpthread >&5
conftest.c:45:1: error: type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int [-Wimplicit-int]
main() {
^
int
conftest.c:50:2: warning: call to undeclared library function 'exit' with type 'void (int) __attribute__((noreturn))'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
exit (
^
conftest.c:50:2: note: include the header <stdlib.h> or explicitly provide a declaration for 'exit'
1 warning and 1 error generated.
```
Clang-16 changed `-Wimplicit-function-declaration` and `-Wimplicit-int`
warnings into errors, see:
https://releases.llvm.org/16.0.0/tools/clang/docs/ReleaseNotes.html#potentially-breaking-changes.
> The -Wimplicit-function-declaration and -Wimplicit-int warnings now
> default to an error in C99, C11, and C17. As of C2x, support for implicit
> function declarations and implicit int has been removed, and the
> warning options will have no effect. Specifying -Wimplicit-int in
> C89 mode will now issue warnings instead of being a noop.
Add an option that when passed, will disable hardening options, and
pass `--disable-hardening` through to configure. Due to the way
we link libssp for Windows builds, they now fail (after #27118),
if building with depends, and configuring with --disable-hardening.
See:
https://github.com/bitcoin/bitcoin/pull/27118#issuecomment-1492606272.
This change would add a depends opiton such that, if someone wants to
build with, for windows, without hardening, they can do so. This may
also be useful when building for debugging.
Use the same workaround we've applied to qrencode, and other packages.
Fontconfig not building is currently a blocker for fuzz/sanitizer infra
upgrades.
For now, this is also more straightforward than bumping the package,
which introduces more complexity/usage of gperf.
87afcb0029b8dab933c122fb8f7263c2e7272731 depends: fix osx build with clang 16 (Cory Fields)
Pull request description:
Current build (using forced system clang as a test) results in:
> error: unknown argument: '-internal-externc-isystem/opt/clang+llvm-16.0.0-x86_64-linux-gnu-ubuntu-18.04/lib/clang/16/include'
For some reason the previous syntax worked with clang 15 and below, but clang 16 requires that the option and value are properly separated.
See [here for an example of upstream using this syntax](https://github.com/llvm/llvm-project/blob/main/clang/test/Driver/crash-report-with-asserts.c#L9).
There is no change in behavior for previous versions.
I'm seeing an additional unrelated problem with linking with system clang, but I'll PR the solution to that separately as it's not as straightforward as this.
ACKs for top commit:
TheCharlatan:
ACK 87afcb0029b8dab933c122fb8f7263c2e7272731
hebasto:
ACK 87afcb0029b8dab933c122fb8f7263c2e7272731
Tree-SHA512: 127037c888c37c6ccd9679e96da34037cc43ccdc07915865a0a5494edb62633e83fc1bd6b1c4bb7a0322f5b59622e10090a31987f38496fb6b306488e9941594
0e02f725482dd30b9f03903074a481af1164411d depends: define `__BSD_VISIBLE` for FreeBSD bdb build (fanquake)
Pull request description:
Required for additional definitions (`IPC_R` & friends), to be available, when compiling under C11, which would otherwise cause compile fails.
See: https://github.com/MarcoFalke/btc_nightly/pull/4.
ACKs for top commit:
hebasto:
ACK 0e02f725482dd30b9f03903074a481af1164411d, tested on FreeBSD 13.1:
Tree-SHA512: 885d4aa341d9668da360cf6dfafb97ce816803c54e76c0a06e448db39a723666d42cd14b3e713d17ecbe33163f5af69924567cf449d679a2db95b36357005d43
1914e470e327091c625f627b4447beb336f7fe5a build: copy config.{guess,sub} post autogen in zmq package (fanquake)
Pull request description:
Otherwise our config.guess and config.sub will be copied over. This problem has been masked by the fact that modern systems ship with versions that recognise all the triplets we use (namely arm64-apple-darwin). However building on ubuntu 20.04 surfaces the issue.
Fixes#26420.
ACKs for top commit:
hebasto:
ACK 1914e470e327091c625f627b4447beb336f7fe5a, tested on Ubuntu 18.04.
Tree-SHA512: dff64c3c62d9f8fc205e5a4dffe8befd58838418d073a15dfe304a0f64b182dfffd9dcf98b53df44bfab905c12a62d03cd5c0f91fa7c4b246ac21ae5f20540fd
a3a2bd9e8ad360a63cc8bdfc365d8bfd25ecc720 ci: Drop no longer needed package-specific flags (Hennadii Stepanov)
071eef1e974f128131afe6c6b5c68a430c64687a build: Propagate user-defined flags to host packages (Hennadii Stepanov)
Pull request description:
On master (4f8b1f8759301d2553183e14f72444a0f1d80725) `{CPP,C,CXX,LD}FLAGS` that are specified in the command line are not propagated to packages:
```
$ make --no-print-directory -C depends print-libevent_cxxflags CXXFLAGS=-some-fancy-flag
libevent_cxxflags=-pipe -O2
```
This PR:
- propagates `{CPP,C,CXX,LD}FLAGS` to host packages:
```
$ make --no-print-directory -C depends print-libevent_cxxflags CXXFLAGS=-some-fancy-flag
libevent_cxxflags= -some-fancy-flag
```
- does not propagate `{CPP,C,CXX,LD}FLAGS` to native packages:
```
$ make --no-print-directory -C depends print-native_b2_cxxflags CXXFLAGS=-some-fancy-flag
native_b2_cxxflags=
```
- actually addresses the https://github.com/bitcoin/bitcoin/pull/23551#issuecomment-973896518
ACKs for top commit:
TheCharlatan:
Code review ACK a3a2bd9e8ad360a63cc8bdfc365d8bfd25ecc720
Tree-SHA512: 243d6b1b0e9c5de46debc36de62a77b6b4d6f638940fd530040c219956ec624e321b0c25290fed164e3a8c88befa7b97b20f765d7b9a428c269b3720f21da099
