If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.
<!--174a7506f384e20aa4161008e828411d-->
Conflicts
Reviewers, this pull request conflicts with the following ones:
#30022 (releases: use LLVM 18 for macOS by fanquake)
#29881 (guix: use GCC 13 to builds releases by fanquake)
#29072 (build: use -no_exported_symbols on macOS by fanquake)
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.
ryanofsky
commented at 1:54 PM on April 26, 2021:
contributor
This definitely seems like a good thing to add support for, but it seems sad to have to drop support for the open source compiler at the same time as adding support for the closed source one. I don't know enough about this to have an informed opinion, though.
EDIT: Just a misunderstanding
fanquake
commented at 1:59 PM on April 26, 2021:
member
but it seems sad to have to drop support for the open source compiler at the same time as adding support for the closed source one.
I might be misunderstanding your comment, but the opposite is happening here. We're migrating away from using Apples, irregularly open sourced tools (cctools, ld64), to just vanilla LLVM (lld), which is entirely open source.
ryanofsky
commented at 2:11 PM on April 26, 2021:
contributor
I might be misunderstanding your comment, but the opposite is happening here. We're migrating away from using Apples, irregularly open sourced tools (cctools, ld64), to just vanilla LLVM (lld), which is entirely open source.
My bad! I thought this was switching from an unsupported apple open-source toolchain to an supported apple closed source toolchain, not to a vanilla toolchain. My blinding hate of apple has kept me from seeing reality! Thanks for the clarification. This all seems very good.
theuni
commented at 6:58 PM on April 26, 2021:
member
Very nice! Strong concept ACK, but obviously we can't use this until all features we need are supported. But it's great to see that linking finally works!
For a little extra context beyond what @fanquake said above, the macOS clang+cctools build has always been a wonky outlier because we have to build our own (very unsupported) toolchain first. LD64 is apple's libre/open-source linker, and there is a community project that maintains a build environment for cross builds.
For a few years, there has been slow development on a darwin functionality for llvm's lld, but it's only really picked up speed and become usable in the last year or two. This PR would bring our Apple builds much more inline with others in that it would finally be using a supported libre/open-source compiler/linker combo.
@fanquake Is cctools still needed at all? LLVM ships bitcode equivalents of most binutils tools (ar, nm, ranlib, etc), I wonder if we can use those instead. Maybe they require lto?
fanquake
commented at 3:06 AM on April 28, 2021:
member
Is cctools still needed at all? LLVM ships bitcode equivalents of most binutils tools (ar, nm, ranlib, etc), I wonder if we can use those instead. Maybe they require lto?
@theuni no cctools is no longer required. I drop the native_cctools as part of this PR and we just use the LLVM tools.
theuni
commented at 4:32 AM on April 28, 2021:
member
@theuni no cctools is no longer required. I drop the native_cctools as part of this PR and we just use the LLVM tools.
Apologies for reading too quickly, I see now that I only looked at the first commit. Turns out the 3rd one is the one I expected :)
fanquake force-pushed on May 1, 2021
fanquake
commented at 6:10 AM on May 1, 2021:
member
Rebased for #21793, and rebased on top of #19817. Made some additional changes, such as renaming the native_cctools package to native_llvm, and removed some now-redundant info from the macdeploy documentation.
Note: I'm pretty sure the use of ZERO_AR_DATE can now be dropped entirely, but have left that out for now.
fanquake force-pushed on May 3, 2021
fanquake force-pushed on Jun 4, 2021
fanquake force-pushed on Jul 20, 2021
fanquake force-pushed on Oct 11, 2021
fanquake force-pushed on Oct 11, 2021
fanquake force-pushed on Oct 11, 2021
fanquake force-pushed on Oct 11, 2021
fanquake force-pushed on Oct 11, 2021
fanquake force-pushed on Oct 11, 2021
fanquake force-pushed on Oct 12, 2021
DrahtBot added the label Needs rebase on Feb 9, 2022
fanquake force-pushed on Feb 11, 2022
DrahtBot removed the label Needs rebase on Feb 11, 2022
fanquake renamed this: POC: LLVM 13 & LLD based macOS toolchain POC: LLVM 14 & LLD based macOS toolchain on Feb 11, 2022
fanquake force-pushed on Feb 11, 2022
fanquake renamed this: POC: LLVM 14 & LLD based macOS toolchain build: LLVM 14 & LLD based macOS toolchain on Feb 11, 2022
fanquake added this to the milestone 24.0 on Feb 11, 2022
fanquake marked this as ready for review on Feb 11, 2022
fanquake referenced this in commit 8fe6f5a6fb on Feb 14, 2022
DrahtBot added the label Needs rebase on Feb 14, 2022
sidhujag referenced this in commit 82740f8612 on Feb 15, 2022
fanquake force-pushed on Mar 8, 2022
fanquake force-pushed on Mar 8, 2022
fanquake force-pushed on Mar 8, 2022
DrahtBot removed the label Needs rebase on Mar 8, 2022
fanquake force-pushed on Mar 8, 2022
fanquake
commented at 2:25 PM on March 8, 2022:
member
Sorry for the noise. This is now pointing at LLVM 14.0.0 rc2, and no longer using binaries I compiled, given the release on GitHub has the binaries we need.
The build is currently failing for Qt, something to follow up with:
Reverting of its changes in mkspecs/features/qt_build_config.prf should fix the error.
I've added a qt patch that does this. However note that bitcoin-qt still isn't being built because of duplicate symbol issues when running our configure checks.
Note that this week the review club is looking at this PR. There are improvements / changes that could be made here, some which I noticed while writing the questions, but I'll leave any followup changes until after Wednesday.
in
depends/patches/qt/no_warnings_for_symbols.patch:14
in
ee74be5e8doutdated
9 | + 10 | + # We have to tell 'ar' to not run ranlib by itself 11 | + QMAKE_AR += -S 12 | +-- 13 | +2.35.1 14 | +
hebasto
commented at 3:39 PM on March 21, 2022:
member
However note that bitcoin-qt still isn't being built because of duplicate symbol issues when running our configure checks.
x86_64-apple-darwin-ld: error: duplicate symbol: __Z10lcQpaFontsv
>>> defined in /home/hebasto/GitHub/bitcoin/depends/x86_64-apple-darwin/lib/libQt5ThemeSupport.a(qgenericunixthemes.o)
>>> defined in /home/hebasto/GitHub/bitcoin/depends/x86_64-apple-darwin/lib/libQt5FontDatabaseSupport.a(qfontengine_coretext.o)
hebasto
commented at 5:37 PM on March 23, 2022:
member
fanquake
commented at 12:20 PM on March 28, 2022:
member
Update ZERO_AR_DATE docs / comments.
lld (and ld64) also respects ZERO_AR_DATE, so I've resolved this TODO by removing the documentation block about cctools and ar.
fanquake force-pushed on Mar 31, 2022
fanquake
commented at 11:24 AM on March 31, 2022:
member
Rebased this on top of #24722, which should resolve the qt issue (libbitcoinconsensus will still cause the CI to fail), and have updated the PR description.
fanquake referenced this in commit a7f0c37c2b on Apr 1, 2022
fanquake force-pushed on Apr 1, 2022
sidhujag referenced this in commit c2266a52f5 on Apr 3, 2022
DrahtBot added the label Needs rebase on Apr 4, 2022
fanquake force-pushed on Apr 4, 2022
DrahtBot removed the label Needs rebase on Apr 4, 2022
PastaPastaPasta referenced this in commit f344e9fc65 on Apr 7, 2022
PastaPastaPasta referenced this in commit 9fb3edaae7 on Apr 11, 2022
fanquake
commented at 7:51 AM on April 13, 2022:
member
LLVM 14.0.1 is out. Will switch to using that once binaries are available.
fanquake force-pushed on Apr 21, 2022
fanquake
commented at 8:15 AM on April 21, 2022:
member
Rebased past #24031. Still waiting on binaries for 14.0.1.
DrahtBot added the label Needs rebase on May 5, 2022
gades referenced this in commit abe009083d on May 8, 2022
fanquake referenced this in commit 298389e3b5 on May 9, 2022
fanquake referenced this in commit e3bab43329 on May 12, 2022
fanquake force-pushed on May 12, 2022
fanquake
commented at 7:47 AM on May 12, 2022:
member
Rebased. Now that 298389e3b51edf561a2b636df0948a232167693a is merged, I've added a commit to use clang-toolchain-14 in the Guix build (which will still fail in this PR). That, and a change to use LLVM 14.0.3 (once the Ubuntu binaries are available) could be split off from here.
DrahtBot removed the label Needs rebase on May 12, 2022
sidhujag referenced this in commit c2552695a0 on May 13, 2022
maflcko added the label DrahtBot Guix build requested on May 16, 2022
DrahtBot added the label Needs rebase on May 18, 2022
fanquake force-pushed on May 18, 2022
DrahtBot removed the label Needs rebase on May 18, 2022
DrahtBot
commented at 11:02 AM on May 19, 2022:
contributor
DrahtBot removed the label Needs rebase on Mar 1, 2023
hebasto
commented at 6:47 PM on March 18, 2023:
member
Tested 46d8f32086d89de919036613b8cb437bc71a9286 on Ubuntu 22.04.
The f41493b9023acb6f3c237f6609f34f99d7e52dc1 commit introduced an error on my system:
$ make -C depends HOST=x86_64-apple-darwin boost FORCE_USE_SYSTEM_CLANG=1
...
Preprocessing boost...
Configuring boost...
tar: option requires an argument -- 'f'
Try 'tar --help' or 'tar --usage' for more information.
...
hebasto referenced this in commit f854a72ae7 on Mar 18, 2023
fanquake force-pushed on Mar 27, 2023
maflcko added the label DrahtBot Guix build requested on Mar 31, 2023
fanquake force-pushed on Apr 5, 2023
fanquake renamed this: build: LLVM 15 & LLD based macOS toolchain build: LLVM 16 & LLD based macOS toolchain on Apr 5, 2023
fanquake marked this as a draft on Apr 5, 2023
fanquake
commented at 2:16 PM on April 5, 2023:
member
I've rebased this, as well as updated our depends build to use LLVM 16.0.0. Guix doesn't yet have LLVM 16 available, either in master or core-updates, so for now, I've bumped the time-machine further, so that it gives us LLVM 15.0.7 there.
With LLVM 16.0.0 in depends, this can be tested / played around with further. However I'll move this back to draft for now.
fanquake force-pushed on Apr 5, 2023
fanquake removed the label DrahtBot Guix build requested on Apr 5, 2023
dekm referenced this in commit 563e5c6d31 on Apr 6, 2023
theuni
commented at 7:57 PM on May 10, 2023:
member
By this, I believe you mean unsupported lld -r? If so, that should be unnecessary with CMake.
Edit: Core is a beast to test with, but using libsecp256k1 as a test-case:
Playing around with the link options: -Wl,-no_fixup_chains -Wl,-bind-at-load (and their opposites) do as expected as checked with: objdump -t --lazy-bind libsecp256k1.2.dylib. When using -fixup_chains (the new default for >=11.0) the lazy bind table is empty as we'd hope.
theuni
commented at 10:59 PM on May 10, 2023:
member
Edit: So, now the only thing stopping us from using vanilla llvm is a minimum version bump, right? So.. I guess it's time for that discussion :)
10.15 has been unsupported for 8 months now...
fanquake renamed this: build: LLVM 16 & LLD based macOS toolchain build: LLVM 15 & LLD based macOS toolchain on May 11, 2023
fanquake force-pushed on May 11, 2023
fanquake
commented at 11:33 AM on May 11, 2023:
member
Shall I go ahead and PR that commit separately?
@theuni sgtm. I've got some related compile flag changes in #27493, but I'm going to just combine most of the relevant changes here. If we get the LLD switchover done for 26.x, then we can skip another bump in the interim.
For now, I've rebased this PR on top of all of your other commits above, and reverted back to LLVM 15.0.6 in depends. Also updated the PR description.
theuni
commented at 3:21 PM on May 11, 2023:
member
@fanquake Do you happen to know what the earliest working clang+lld combo would be? Obviously 15 and 16 work, did 13 or 14 have the required options? Just curious because it'll be good to know what the minimum supported vanilla combo (outside of guix/depends) is as that'll become our new requirement.
fanquake
commented at 5:51 PM on May 11, 2023:
member
did 13 or 14 have the required options?
IIRC I think so. I'l go back and check, so we can establish a minimum required version.
fanquake referenced this in commit 8bfe503ec6 on May 14, 2023
fanquake force-pushed on May 14, 2023
sidhujag referenced this in commit 1d95fa1c0d on May 15, 2023
theuni
commented at 10:13 PM on May 16, 2023:
member
Which I suppose means that fixup_chains isn't actually being used in this PR. I'll check around in the logs and if I'm right about that I'll work up a test that this PR should fail as-is.
Edit: yep:
checking whether the linker accepts -Wl,-bind_at_load... no
checking whether the linker accepts -Wl,-fixup_chains... no
I'll poke around with Lief to see if we can enforce fixup_chains there.
fanquake referenced this in commit 25202cace9 on May 25, 2023
sidhujag referenced this in commit 4acbb43480 on May 26, 2023
fanquake force-pushed on Jun 2, 2023
DrahtBot added the label Needs rebase on Jun 14, 2023
fanquake force-pushed on Jun 16, 2023
DrahtBot removed the label Needs rebase on Jun 16, 2023
DrahtBot added the label Needs rebase on Jun 22, 2023
fanquake force-pushed on Jun 22, 2023
DrahtBot removed the label Needs rebase on Jun 22, 2023
fanquake force-pushed on Jun 22, 2023
dekm referenced this in commit 4eef3195af on Jun 26, 2023
dekm referenced this in commit 1cc903a5e5 on Jun 26, 2023
fanquake referenced this in commit 35b01e8504 on Jun 27, 2023
fanquake force-pushed on Jun 27, 2023
maflcko added the label DrahtBot Guix build requested on Jun 27, 2023
tobtoht
commented at 1:51 PM on June 27, 2023:
none
powerpc64-linux-gnu build is failing with:
Backtrace:
In srfi/srfi-1.scm:
586:29 19 (map1 (#<<manifest-entry> name: "python-lief" versio?> ?))
586:17 18 (map1 (#<<manifest-entry> name: "powerpc64-linux-gnu-t?>))
In guix/profiles.scm:
1930:19 17 (_ _)
In guix/packages.scm:
1348:17 16 (supported-package? #<package powerpc64-linux-gnu-tool?> ?)
In guix/memoization.scm:
101:0 15 (_ #<hash-table 7f27a126c4c0 282/443> #<package powerp?> ?)
In guix/packages.scm:
1318:12 14 (_)
In srfi/srfi-1.scm:
460:18 13 (fold #<procedure 7f27a03a2560 at guix/packages.scm:13?> ?)
In guix/packages.scm:
1322:42 12 (_ _ ("x86_64-linux" "i686-linux"))
In guix/memoization.scm:
101:0 11 (_ #<hash-table 7f27a126c4c0 282/443> #<package glibc-?> ?)
In guix/packages.scm:
1318:12 10 (_)
In srfi/srfi-1.scm:
460:18 9 (fold #<procedure 7f27a03a75c0 at guix/packages.scm:13?> ?)
In guix/packages.scm:
1322:42 8 (_ _ ("x86_64-linux" "i686-linux"))
In guix/memoization.scm:
101:0 7 (_ #<hash-table 7f27a126c4c0 282/443> #<package linux-?> ?)
In guix/packages.scm:
1326:37 6 (_)
1588:16 5 (package->bag _ _ _ #:graft? _)
1693:43 4 (thunk)
In guix/build-system/gnu.scm:
187:19 3 (arguments _)
In gnu/packages/cross-base.scm:
389:34 2 (loop (#:phases (modify-phases %standard-phases # ?) ?) #)
In ice-9/boot-9.scm:
1685:16 1 (raise-exception _ #:continuable? _)
1685:16 0 (raise-exception _ #:continuable? _)
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
ERROR:
1. &platform-not-found-error: "powerpc64-linux-gnu"
fanquake
commented at 1:53 PM on June 27, 2023:
member
powerpc64-linux-gnu build is failing with:
Thanks, thats's already mentioned as a known issue here: #27897, which also does a time-machine bump. You don't need to build for powerpc to test the two macOS build, if you want to test the changes here.
DrahtBot
commented at 12:51 PM on June 28, 2023:
contributor
In the meantime, I've rebased this, and updated depends to use LLVM 16.0.4. There aren't currently x86_64 binaries available for 16.0.5 or 16.0.6.
fanquake
commented at 4:56 PM on June 30, 2023:
member
Also added a commit to drop explicit -bind_at_load usage from configure for now. Cleaned up the PR description and instructions. Note that Guix build are basically expected to fail at this point. However if anyone would like to test, cross-compilation can be done using depends.
DrahtBot removed the label Needs rebase on Jun 30, 2023
DrahtBot added the label CI failed on Jul 1, 2023
DrahtBot removed the label CI failed on Jul 6, 2023
fanquake force-pushed on Jul 27, 2023
DrahtBot added the label CI failed on Jul 27, 2023
fanquake force-pushed on Aug 14, 2023
fanquake
commented at 12:30 PM on August 14, 2023:
member
Re-rebased on #27897, and updated 6f6552688233e35a56f7a4c428c99c657150d313 to include lld-15 & lld-as-ld-wrapper-15. Using lld-as-ld-wrapper seems to be the best way to make build systems (like Qts) work with LLD.
DrahtBot removed the label CI failed on Aug 14, 2023
DrahtBot added the label Needs rebase on Aug 22, 2023
fanquake force-pushed on Aug 23, 2023
fanquake
commented at 1:47 PM on August 23, 2023:
member
Rebased and updated to be based on #28328. Still need to get LLVM/Clang 16+ upstreamed into Guix.
DrahtBot removed the label Needs rebase on Aug 23, 2023
DrahtBot added the label CI failed on Aug 23, 2023
DrahtBot added the label Needs rebase on Aug 24, 2023
fanquake force-pushed on Aug 24, 2023
DrahtBot removed the label Needs rebase on Aug 24, 2023
fanquake referenced this in commit 03675b2ba3 on Aug 26, 2023
fanquake renamed this: build: LLVM 16 & LLD based macOS toolchain build: LLD based macOS toolchain on Aug 26, 2023
fanquake force-pushed on Aug 26, 2023
DrahtBot removed the label CI failed on Aug 26, 2023
fanquake referenced this in commit 8371914604 on Aug 27, 2023
fanquake force-pushed on Aug 27, 2023
maflcko added the label DrahtBot Guix build requested on Aug 27, 2023
fanquake force-pushed on Aug 28, 2023
DrahtBot removed the label DrahtBot Guix build requested on Aug 28, 2023
fanquake force-pushed on Sep 7, 2023
Frank-GER referenced this in commit 74569677f6 on Sep 8, 2023
Frank-GER referenced this in commit c6be2a4da0 on Sep 8, 2023
DrahtBot added the label Needs rebase on Sep 20, 2023
fanquake force-pushed on Sep 20, 2023
DrahtBot removed the label Needs rebase on Sep 20, 2023
maflcko added the label DrahtBot Guix build requested on Sep 21, 2023
DrahtBot removed the label DrahtBot Guix build requested on Sep 21, 2023
maflcko added the label DrahtBot Guix build requested on Sep 21, 2023
DrahtBot
commented at 3:42 AM on September 22, 2023:
contributor
DrahtBot removed the label DrahtBot Guix build requested on Sep 22, 2023
fanquake force-pushed on Oct 3, 2023
DrahtBot added the label Needs rebase on Oct 3, 2023
fanquake force-pushed on Oct 3, 2023
DrahtBot removed the label Needs rebase on Oct 3, 2023
fanquake force-pushed on Oct 6, 2023
DrahtBot added the label CI failed on Oct 6, 2023
PastaPastaPasta referenced this in commit fddae491fc on Oct 11, 2023
PastaPastaPasta referenced this in commit 06e941c615 on Oct 27, 2023
PastaPastaPasta referenced this in commit a90fa33f69 on Nov 3, 2023
fanquake force-pushed on Nov 13, 2023
fanquake force-pushed on Nov 13, 2023
fanquake
commented at 10:32 AM on November 13, 2023:
member
Rebased on #28580 (LLVM 17 in Guix) and #28783, which should be the last blockers for this.
in
depends/patches/qt/no_warnings_for_symbols.patch:8
in
5dd066d430outdated
0 | @@ -0,0 +1,11 @@ 1 | +--- a/qtbase/mkspecs/features/mac/no_warn_empty_obj_files.prf 2 | ++++ b/qtbase/mkspecs/features/mac/no_warn_empty_obj_files.prf 3 | +@@ -1,7 +1,7 @@ 4 | + # Prevent warnings about object files without any symbols. This is a common 5 | + # thing in Qt as we tend to build files unconditionally, and then use ifdefs 6 | + # to compile out parts that are not relevant. 7 | +-QMAKE_RANLIB += -no_warning_for_no_symbols 8 | ++# QMAKE_RANLIB += -no_warning_for_no_symbols
5dd066d4301342859e124abcd61141fbb8b5a003: can you clarify in the commit message or patch file why we're disabling this? Since the comment suggests it's needed.
fanquake
commented at 12:10 PM on November 13, 2023:
IIRC this was because LLVM ranlib didn't support this option, so qt would fail to build.
hebasto
commented at 11:55 AM on November 13, 2023:
member
Rebased on #28580 (LLVM 17 in Guix) and #28783, which should be the last blockers for this.
Why #28783 is considered as a blocker for this PR?
fanquake
commented at 11:56 AM on November 13, 2023:
member
Why #28783 is considered as a blocker for this PR?
LLD will output spurious warnings about not implementing bind_at_load, which we can avoid by merging #28783.
in
depends/packages/native_libtapi.mk:9
in
e65a429b6aoutdated
fanquake
commented at 12:11 PM on November 13, 2023:
It was, seems it returned in a rebase. Will drop it on the next push.
fanquake force-pushed on Nov 13, 2023
Sjors
commented at 2:52 PM on November 13, 2023:
member
Guix building df71f448cdaf429f54367ab251e21e628c1903d3 is having issues for me:
Extracting libevent...
/home/guix/depends-sources-cache/libevent-2.1.12-stable.tar.gz: OK
Preprocessing libevent...
Configuring libevent...
checking for a BSD-compatible install... /home/guix/.guix-profile/bin/install -c
checking whether build environment is sane... yes
checking for x86_64-apple-darwin-strip... no
checking for strip... strip
configure: WARNING: using cross tools not prefixed with host triplet
checking for a thread-safe mkdir -p... /home/guix/.guix-profile/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether make supports nested variables... (cached) yes
checking whether make supports the include directive... yes (GNU style)
checking for x86_64-apple-darwin-gcc... env -u C_INCLUDE_PATH -u CPLUS_INCLUDE_PATH -u OBJC_INCLUDE_PATH -u OBJCPLUS_INCLUDE_PATH -u CPATH -u LIBRARY_PATH /home/guix/.guix-profile/bin/clang --target=x86_64-apple-darwin -mmacosx-version-min=11.0 -B/bitcoin/depends/x86_64-apple-darwin/native/bin -mlinker-version=711 -isysroot/home/guix/SDKs/Xcode-12.2-12B45b-extracted-SDK-with-libcxx-headers -iwithsysroot/usr/include -iframeworkwithsysroot/System/Library/Frameworks
checking whether the C compiler works... no
configure: error: in `/bitcoin/depends/work/build/x86_64-apple-darwin/libevent/2.1.12-stable-ab81f19d3b8':
configure: error: C compiler cannot create executables
See `config.log' for more details
make: *** [funcs.mk:292: /bitcoin/depends/x86_64-apple-darwin/.libevent_stamp_configured] Error 77
make: Leaving directory '/bitcoin/depends'
Can add more details...
fanquake
commented at 2:53 PM on November 13, 2023:
member
Can add more details...
I'd suggest reviewing the base PRs instead, for now (pretty sure this is just -fuse-ld usage that needs tidying up).
DrahtBot removed the label CI failed on Nov 13, 2023
fanquake force-pushed on Nov 14, 2023
fanquake force-pushed on Dec 1, 2023
PastaPastaPasta referenced this in commit 0db79169df on Dec 6, 2023
PastaPastaPasta referenced this in commit 1c826c09f4 on Dec 7, 2023
fanquake force-pushed on Dec 11, 2023
fanquake
commented at 4:36 PM on December 11, 2023:
member
fanquake referenced this in commit 4b1196a985 on Dec 22, 2023
fanquake force-pushed on Dec 22, 2023
maflcko added the label DrahtBot Guix build requested on Dec 22, 2023
fanquake force-pushed on Dec 22, 2023
in
depends/hosts/darwin.mk:25
in
c857bc5d33outdated
25 | + 26 | +# Make-only lowercase function 27 | +lc = $(subst A,a,$(subst B,b,$(subst C,c,$(subst D,d,$(subst E,e,$(subst F,f,$(subst G,g,$(subst H,h,$(subst I,i,$(subst J,j,$(subst K,k,$(subst L,l,$(subst M,m,$(subst N,n,$(subst O,o,$(subst P,p,$(subst Q,q,$(subst R,r,$(subst S,s,$(subst T,t,$(subst U,u,$(subst V,v,$(subst W,w,$(subst X,x,$(subst Y,y,$(subst Z,z,$1)))))))))))))))))))))))))) 28 | + 29 | +# For well-known tools provided by LLVM, make sure that their well-known 30 | +# variable is set to the full path of the tool, just like how AC_PATH_{TOO,PROG}
hebasto
commented at 11:40 AM on December 22, 2023:
# variable is set to the full path of the tool, just like how AC_PATH_{TOOL,PROG}
fanquake
commented at 11:40 AM on December 22, 2023:
member
Rebased after #28880. Cleaned up the commits a bit. Doesn't work yet, because Qt doesn't build..
Also rethinking the best approach here a bit, as we've now essentially got to accomodate 3 different builds for macOS:
Building for mac, on mac, using Apple Clang & ld64 (which also doesn't like -fuse-ld=lld)
Building for mac, on Linux, using our downloaded LLVM (Clang + lld + tools)
Building for mac, in Guix, using Guix's Clang + our downloaded lld + tools??
Or shift further into using all Guix linker + tools, or, try drop Guix Clang?
in
contrib/macdeploy/README.md:60
in
c857bc5d33outdated
55 | @@ -56,29 +56,14 @@ The `sha256sum` should be `c0c2e7bb92c1fee0c4e9f3a485e4530786732d6c6dd9e9f418c28
56 |
57 | ## Deterministic macOS App Notes
58 |
59 | -macOS Applications are created in Linux by combining a recent `clang` and the Apple 60 | -`binutils` (`ld`, `ar`, etc). 61 | +macOS Applications are created in Linux by combining a recent LLVM (`clang`, 62 | +`lld` + binutils)
hebasto
commented at 11:46 AM on December 22, 2023:
nit: As the word 'combining' has only one object, rather than two as it was before, it seems reasonable to drop it altogether.
fanquake
commented at 11:47 AM on December 22, 2023:
Given this doesn't yet work, and we might be reithinking the approach (which might render this text irrelevant, I'll just leave stuff like this for now.
Sjors
commented at 12:18 PM on December 22, 2023:
member
Building for mac, in Guix, using Guix's Clang + our downloaded lld + tools??
Or shift further into using all Guix linker + tools, or, try drop Guix Clang?
Would you say that (temporarily) using Apple's Clang instead of Guix would still make this PR an overall improvement for macOS reproducibility? If so, and if makes things easier, that could make sense.
DrahtBot added the label CI failed on Dec 22, 2023
DrahtBot
commented at 6:45 PM on December 22, 2023:
contributor
DrahtBot removed the label DrahtBot Guix build requested on Dec 22, 2023
maflcko
commented at 4:05 PM on January 5, 2024:
member
Building for mac, on Linux, using our downloaded LLVM (Clang + lld + tools)
Building for mac, in Guix, using Guix's Clang + our downloaded lld + tools??
Or shift further into using all Guix linker + tools, or, try drop Guix Clang?
I think the benefit of using guix (over downloading a random binary blob from someone else's computer) is that cross compilation to macOS works on more architectures than the uploads of the llvm binaries. (For example riscv64)
So simply requiring guix to do a macOS depends build (and nuking clang from depends, or keeping it as a fallback, if needed) seems preferable?
fanquake
commented at 4:11 PM on January 5, 2024:
member
fanquake
commented at 11:17 AM on January 10, 2024:
member
Pushed up a few more improvements.
Somewhat annoyingly, some distros (Ubuntu) only ship llvm-libtool-darwin with a version suffix, i.e llvm-libtool-darwin-17, however many others (Fedora, Alpine etc) do not do this. I think we should just set darwin_LIBTOOL=llvm-libtool-darwin as a best effort, and I've added a note to the depends readme, that if anyone sees issues, they should set LIBTOOL=llvm-libtool-darwin-version when calling make.
The CI failure here is a bit odd, because it only happens for ZeroMQ, and only when using what looks like clang-14? This doesn't happen when using newer Clang, or when doing a Guix build. The actual error is:
It's failing to find -lstdc++ while running the AX_CXX_COMPILE_STDCXX_11 macro (zeromq also ships an ancient version of AX_CXX_COMPILE_STDCXX), but it shouldn't be trying to use that in any case. We want libc++.
fanquake force-pushed on Jan 10, 2024
fanquake
commented at 11:41 AM on January 10, 2024:
member
The CI failure here is a bit odd, because it only happens for ZeroMQ, and only when using what looks like clang-14?
I think the solution to this is just to keep our current Clang version requirement for macOS cross-compilation. Currently, we vendor our own Clang (17) and use 17 in Guix. Switching to using system Clang doesn't mean we now need to support clang-13 + when building for macOS, because we never did previously, and no-one building Core could have been using a version other than the only one we supported (17).
So, when switching to system Clang, we retain the Clang 17 requirement (for macOS). The CI should also be using 17, because it should match what we are doing in Guix. So I've now switched it to a newer version of Ubuntu (24.04), which ships clang-17 by default.
In regards to the ZeroMQ failure, my suspicion is that the failure is realted to -nostdlibinc and earlier versions of Clang.
in
ci/test/00_setup_env_mac.sh:15
in
39895e0c30outdated
This will break in a few months, when clang will become an alias for clang-18
fanquake
commented at 1:30 PM on January 10, 2024:
Sure. I guess at that point we'll have to change it. Not sure what else to do given this is what Ubuntu ships. I assume we'll have to make other changes at the same time, if the CI is changing compilers etc out from under us?
fanquake
commented at 1:36 PM on January 10, 2024:
I guess we can also just explictly install clang-17 and llvm-17 here, and then not have to worry about things, until those packages no-longer exist.
However that would also require more changes, (not clear we want to hardcode -17 further ((inside depends)), and make our build less generic, so not sure.
TheCharlatan
commented at 1:54 PM on January 10, 2024:
More changes as in being able to handle setting CC to e.g. clang-17 for darwin depends? That seems worthwhile, no?
fanquake
commented at 1:57 PM on January 10, 2024:
More changes as in being able to handle setting CC to e.g. clang-17 for darwin depends?
That should already work ok, I mean, hardcoding things like command -v clang-17 in depends. If the preference is to install the *-17 toolchain, and pass CC and CXX explicitly, we can do that. We'd have to do that with everything, AR, RANLIB, LIBTOOL, NM etc.
Sure. I guess at that point we'll have to change it.
Well, if it is going to be changed, it may be better to do the change now. Otherwise it just seems like extra steps to reach the same point eventually?
fanquake
commented at 2:01 PM on January 10, 2024:
Well, if it is going to be changed, it may be better to do the change now.
Change it to what though? The problem is that Ubuntu only ships this binary with a version suffix. We can't use something generic, and we want to use version 17.
apt install clang-17, like in the tidy task, it is also possible to export a variable to set CROSS_LLVM_V="17" and then use that variable, where needed.
fanquake
commented at 2:12 PM on January 10, 2024:
Ok, done as I suggested above.
fanquake force-pushed on Jan 10, 2024
fanquake force-pushed on Jan 10, 2024
fanquake force-pushed on Jan 10, 2024
fanquake
commented at 2:13 PM on January 10, 2024:
member
Moved to explicitly installing *-17. Added the missing darwin_STRIP=llvm-strip .
fanquake force-pushed on Jan 10, 2024
theuni
commented at 3:01 PM on January 10, 2024:
member
Re libtool: As far as I can see, it's only used for miniupnpc/libnatpnp?
If that's the case, I don't think it's worth the trouble of having users work around it.
I'd suggest we either:
patch out libtool in the Makefiles and use ar, then drop our libtool machinery entirely.
Switch to their cmake builds where I assume libtool is unused.
I have a branch with commits to do the latter as part of a larger CMake switch, but maybe now is a good time to take those two? (If so, ignore the native_cmake part, that was just to get myself bootstrapped.)
Edit: If there's interest in the above I can PR it separately.
fanquake
commented at 3:11 PM on January 10, 2024:
member
Edit: If there's interest in the above I can PR it separately.
Sure, I can rebase on top of that PR, if you want to open it.
fanquake force-pushed on Jan 10, 2024
fanquake
commented at 5:04 PM on January 10, 2024:
member
Would still like to see them PR'd separately, but I cherry-picked the two relevant commits, dropped native_cmake, and have dropped anything libtool related here.
fanquake
commented at 5:17 PM on January 10, 2024:
member
The remaining issue here is with make -C depends CC= CXX= usage. If we override, we lose the c(xx) flags which are currently embedded into darwin_C(XX), which means things don't compile. This is why this PR works fine, if you just invoke make -C depends HOST=arm64-apple-darwin, with clang installed, but if you make -C depends HOST=arm64-apple-darwin CC=clang-17 CXX=clang++-17, like we want to do in the CI, things don't quite work because we loose flags, like --target, and clang things it's compiling for Linux etc. So we'll need to move (some) flags into darwin_C(XX)FLAGS.
If you Guix build this branch now, everything will compile fine, but it will fail during the test-security check stage, that issue should also be easily resolved.
theuni
commented at 6:12 PM on January 10, 2024:
member
Would still like to see them PR'd separately, but I cherry-picked the two relevant commits, dropped native_cmake, and have dropped anything libtool related here.
It's been quite a while since I worked on those, I don't remember if they were completely merge-ready (I suspect windows cross might be broken for ex.). Playing with them locally now.
theuni
commented at 7:09 PM on January 10, 2024:
member
Would still like to see them PR'd separately, but I cherry-picked the two relevant commits, dropped native_cmake, and have dropped anything libtool related here.
It's been quite a while since I worked on those, I don't remember if they were completely merge-ready (I suspect windows cross might be broken for ex.). Playing with them locally now.
Updated my branch. Up to you if you want to do this here or not.
maflcko
commented at 10:35 AM on January 11, 2024:
member
This is why this PR works fine, if you just invoke make -C depends HOST=arm64-apple-darwin, with clang installed, but if you make -C depends HOST=arm64-apple-darwin CC=clang-17 CXX=clang++-17, like we want to do in the CI
If picking the clang version via depends is not a use case to support outside the CI, what about aliasing clang=clang-17 in the CI container? Obviously fixing depends would be cleaner, but if it is only used by CI, then it may not be needed.
The only requirement for the CI is that the version is pinned (or that this pull request is put on hold until Ubuntu bumped to clang-18, in which case it will remain pinned by itself)
fanquake
commented at 10:48 AM on January 11, 2024:
member
Want to punt the libtool removal to a follow-up PR to avoid slowing this one down?
Looks like the cmake changes will require some additional CI changes at least. I think we can still open an additional PR, with upnpc and natpmp, and get that merged. Seems cleanest to just nuke libtool here, and avoid interim workarounds for Ubuntus binarys etc. I'll pull your new commits in here in any case.
If picking the clang version via depends is not a use case to support outside the CI,
We do want to support that, but only with clang-17+. The issue is the flags being embedded into c/cxx, which is an artifact of previous problems. We can move the flags out, and this will be solved.
fanquake referenced this in commit 3b195102be on Jan 11, 2024
fanquake referenced this in commit 5c4a32f8dd on Jan 11, 2024
fanquake referenced this in commit f3ca6db8d3 on Jan 11, 2024
fanquake referenced this in commit 1c4a9c1cf3 on Jan 11, 2024
fanquake force-pushed on Jan 11, 2024
fanquake
commented at 2:26 PM on January 11, 2024:
member
Rebased on top of adding CMake into all CIs, the newer upnpc / libnatmp / dropping libtool commits, and added a new commit to deduplicate usage of -mmaxosx-version-min.
fanquake referenced this in commit d862ae8173 on Jan 11, 2024
fanquake force-pushed on Jan 11, 2024
fanquake referenced this in commit 12865d21ef on Jan 11, 2024
fanquake force-pushed on Jan 11, 2024
fanquake force-pushed on Jan 12, 2024
fanquake force-pushed on Jan 16, 2024
fanquake referenced this in commit c818607ed5 on Jan 17, 2024
DrahtBot added the label Needs rebase on Jan 17, 2024
fanquake force-pushed on Jan 17, 2024
DrahtBot removed the label Needs rebase on Jan 17, 2024
fanquake force-pushed on Jan 24, 2024
fanquake force-pushed on Jan 29, 2024
fanquake force-pushed on Jan 29, 2024
fanquake force-pushed on Jan 29, 2024
fanquake
commented at 4:45 PM on January 29, 2024:
member
Pushed up one WIP commit. This almost works how we want it too:
Depends builds using system clang, i.e make -C depends/ HOST=arm64-apple-darwin -j17. Tested on x86_64 Ubuntu with Ubuntu clang version 17.0.6 (3).
Depends builds with overriden CC & CXX, i.e make -C depends/ HOST=arm64-apple-darwin CC=clang-17 CXX=clang++-17. See the CI (which fails during make deploy due to no otool), also tested on aarch64 Fedora with clang version 17.0.6 (Fedora 17.0.6-4.fc40).
Guix builds are ~95% there, but fail during test-security-check because they invoke ld:
CXXLD bitcoin-cli
ld64.lld: warning: Option `-bind_at_load' is not yet implemented. Stay tuned...
AR minisketch/libminisketch.a
ld64.lld: warning: Option `-bind_at_load' is not yet implemented. Stay tuned...
ld64.lld: warning: Option `-bind_at_load' is not yet implemented. Stay tuned...
CXXLD univalue/test/unitester
ld64.lld: warning: Option `-bind_at_load' is not yet implemented. Stay tuned...
ld64.lld: warning: Option `-bind_at_load' is not yet implemented. Stay tuned...
ld64.lld: warning: Option `-bind_at_load' is not yet implemented. Stay tuned...
CXXLD univalue/test/object
ld64.lld: warning: Option `-bind_at_load' is not yet implemented. Stay tuned...
AR libtest_util.a
CXXLD test/test_bitcoin
ld64.lld: warning: Option `-bind_at_load' is not yet implemented. Stay tuned...
make[2]: Leaving directory '/distsrc-base/distsrc-cb758c13eb6c-arm64-apple-darwin/src'
make[1]: Leaving directory '/distsrc-base/distsrc-cb758c13eb6c-arm64-apple-darwin/src'
Making all in doc/man
make[1]: Entering directory '/distsrc-base/distsrc-cb758c13eb6c-arm64-apple-darwin/doc/man'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/distsrc-base/distsrc-cb758c13eb6c-arm64-apple-darwin/doc/man'
make[1]: Entering directory '/distsrc-base/distsrc-cb758c13eb6c-arm64-apple-darwin'
make[1]: Nothing to be done for 'all-am'.
make[1]: Leaving directory '/distsrc-base/distsrc-cb758c13eb6c-arm64-apple-darwin'
ld: unrecognised emulation mode: acosx_version_min
Supported emulations: elf_x86_64 elf32_x86_64 elf_i386 elf_iamcu elf_l1om elf_k1om
clang: error: linker command failed with exit code 1 (use -v to see invocation)
E
======================================================================
ERROR: test_MACHO (__main__.TestSecurityChecks)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/distsrc-base/distsrc-cb758c13eb6c-arm64-apple-darwin/./contrib/devtools/test-security-check.py", line 118, in test_MACHO
arch = get_arch(cc, source, executable)
File "/distsrc-base/distsrc-cb758c13eb6c-arm64-apple-darwin/./contrib/devtools/test-security-check.py", line 45, in get_arch
subprocess.run([*cc, source, '-o', executable], check=True)
File "/gnu/store/r4ylp5184rybw9s3lpg49hb27fwgk03i-python-minimal-3.10.7/lib/python3.10/subprocess.py", line 524, in run
raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['/root/.guix-profile/bin/clang', '--target=arm64-apple-darwin', '-isysroot/root/SDKs/Xcode-15.0-15A240d-extracted-SDK-with-libcxx-headers', '-nostdlibinc', '-iwithsysroot/usr/include/c++/v1', '-iwithsysroot/usr/include', '-iframeworkwithsysroot/System/Library/Frameworks', 'test1.c', '-o', 'test1']' returned non-zero exit status 1.
----------------------------------------------------------------------
Ran 1 test in 0.117s
FAILED (errors=1)
make: *** [Makefile:1417: test-security-check] Error 1
Linking of all our bins happens with lld, and this shouldn't happen given lld-as-ld-wrapper, following up.
fanquake force-pushed on Jan 30, 2024
fanquake
commented at 11:25 AM on January 30, 2024:
member
Added a change to fix the make deploy CI failure. It involves switching from otool, to llvm-objdump, which for our needs (listing shared lib deps) is a drop-in replacement with the right flags (--macho--dylibs-used). We could have used llvm-otool, but we'd have the same problem that we would have had with llvm-libtool, which is that some distros (Ubuntu) only ship this binary with a version-suffix, which makes it annoying to find/use. Using llvm-objdump avoids this issue, and it's nicer to move to a less apple-specific tool.
fanquake force-pushed on Jan 30, 2024
DrahtBot removed the label CI failed on Jan 30, 2024
fanquake force-pushed on Feb 2, 2024
fanquake
commented at 9:34 AM on February 2, 2024:
member
Squashed down the changes, and did some Guix cleanup.
We can entirely remove the GCC toolchain from the macOS build now. Apart from removing unused deps,
my other reason to do this was to make sure that ld wasn't even in the build environment, so couldn't be getting used over lld.
However this has come with a new issue. Qt now fails to build, because it's trying to build qmake with g++,
which no-longer exists. i.e
Configuring qt...
Creating qmake...
make[1]: Entering directory '/bitcoin/depends/work/build/arm64-apple-darwin/qt/5.15.11-f4932583bde/qtbase/qmake'
make[1]: g++: No such file or directory
make[1]: *** [Makefile:250: main.o] Error 127
This would seem to be a bug in any case, because if we are using a clang toolchain, there shouldn't be an assumption that GCC is installed. So we need to make it use clang++ instead.
maflcko added the label DrahtBot Guix build requested on Feb 2, 2024
maflcko removed the label DrahtBot Guix build requested on Feb 2, 2024
fanquake force-pushed on Feb 2, 2024
DrahtBot added the label CI failed on Feb 2, 2024
maflcko added the label DrahtBot Guix build requested on Feb 6, 2024
DrahtBot
commented at 8:20 PM on February 6, 2024:
contributor
TheCharlatan
commented at 8:38 AM on February 7, 2024:
Why is this overriding CC and CXX here (and below)? Seems like this causes the current CI failure, or at least calling this darwin_CC and darwin_CXX allows me to properly override everything with AR=llvm-ar-17 OBJDUMP=llvm-objdump-17 RANLIB=llvm-ranlib-17 STRIP=llvm-strip-17 CC=clang-17 CXX=clang++-17 make HOST=arm64-apple-darwin -j 30 and complete a depends build on my machine.
fanquake
commented at 8:45 AM on February 7, 2024:
We have to override below, otherwise a build where the user sets CC and CCX won't work, because there will be no target or SDK flags, and all configure checks / compilation will fail.
TheCharlatan
commented at 9:02 AM on February 7, 2024:
Right, what I'm suggesting is keeping the override lines and:
DrahtBot added the label Needs rebase on Mar 12, 2024
fanquake force-pushed on Mar 12, 2024
DrahtBot removed the label Needs rebase on Mar 12, 2024
DrahtBot added the label Needs rebase on Mar 14, 2024
fanquake force-pushed on Mar 14, 2024
DrahtBot removed the label Needs rebase on Mar 14, 2024
fanquake referenced this in commit 2f606c87d3 on Mar 26, 2024
fanquake referenced this in commit ac9879c061 on Mar 26, 2024
fanquake referenced this in commit 91440efb1e on Mar 26, 2024
fanquake referenced this in commit 20856931ea on Mar 26, 2024
fanquake referenced this in commit 039af15e99 on Mar 26, 2024
fanquake referenced this in commit fb04a93322 on Mar 26, 2024
fanquake referenced this in commit 93f22a662f on Mar 26, 2024
fanquake referenced this in commit 2417ec2550 on Mar 26, 2024
fanquake referenced this in commit efa00c102b on Mar 26, 2024
fanquake referenced this in commit 1ab59c7d11 on Mar 27, 2024
fanquake referenced this in commit 89e12f6a4b on Mar 27, 2024
fanquake referenced this in commit 430f319f73 on Mar 27, 2024
fanquake referenced this in commit 3d37ed490a on Apr 1, 2024
DrahtBot added the label Needs rebase on Apr 1, 2024
fanquake force-pushed on Apr 1, 2024
DrahtBot removed the label Needs rebase on Apr 1, 2024
PastaPastaPasta referenced this in commit 4116404b3e on Apr 3, 2024
DrahtBot added the label Needs rebase on Apr 4, 2024
fanquake force-pushed on Apr 4, 2024
DrahtBot removed the label Needs rebase on Apr 4, 2024
PastaPastaPasta referenced this in commit 64cb78a6a7 on Apr 4, 2024
fanquake referenced this in commit 5d91933c1a on Apr 5, 2024
DrahtBot added the label Needs rebase on Apr 5, 2024
DrahtBot
commented at 3:25 PM on April 5, 2024:
contributor
<!--cf906140f33d8803c4a75a2196329ecb-->
🐙 This pull request conflicts with the target branch and needs rebase.
janus referenced this in commit 505743168c on Apr 6, 2024
fanquake referenced this in commit 0723060e28 on Apr 9, 2024
fanquake referenced this in commit 1f80cc6191 on Apr 9, 2024
PastaPastaPasta referenced this in commit 12d2e828fb on Apr 12, 2024
fanquake referenced this in commit 234639b2bd on Apr 16, 2024
fanquake referenced this in commit 16fdd642b1 on Apr 16, 2024
PastaPastaPasta referenced this in commit 41931f3888 on Apr 23, 2024
luke-jr referenced this in commit b84f300926 on Apr 24, 2024
PastaPastaPasta referenced this in commit a1dc17dcb1 on Apr 24, 2024
fanquake referenced this in commit 7b6338d75b on Apr 25, 2024
fanquake referenced this in commit e5f464be32 on Apr 26, 2024
fanquake referenced this in commit 89abd3467d on Apr 27, 2024
fanquake referenced this in commit 34848d4bbe on Apr 27, 2024
PastaPastaPasta referenced this in commit 439f6d16b2 on Apr 29, 2024
fanquake referenced this in commit 30c54c1f1b on May 3, 2024
fanquake referenced this in commit 0ec6374751 on May 3, 2024
fanquake referenced this in commit dc17ec1cde on May 6, 2024
fanquake referenced this in commit c9310b7c45 on May 6, 2024
fanquake referenced this in commit 9a03f4ed54 on May 7, 2024
fanquake referenced this in commit 7f5ac4520d on May 8, 2024
fanquake referenced this in commit 986c63dcad on May 9, 2024
fanquake referenced this in commit b671fba5c2 on May 9, 2024
fanquake force-pushed on May 9, 2024
fanquake referenced this in commit c132f26456 on May 9, 2024
fanquake force-pushed on May 9, 2024
fanquake added the label DrahtBot Guix build requested on May 9, 2024
fanquake
commented at 4:22 PM on May 9, 2024:
member
Redone this to be less convoluted. No-longer dropping our native LLVM Clang in here; just switching to LLD, dropping cctools & libtapi. Will do Clang in a followup, it gets too messy otherwise. Currently based on #29739 and #30074. Can split the other cctools changes if wanted, but they are pretty simple. The qrencode AR change likely needs to be applied globally in depends.
in
depends/packages/qrencode.mk:11
in
b6ad14be08outdated
I think you're right. Might have added this as belt-and-suspenders, but have checked again with non-Guix builds, and I still see the correct lld used, even on systems with other llds installed & similar.
fanquake referenced this in commit 4d3f1d08db on May 11, 2024
fanquake force-pushed on May 11, 2024
fanquake force-pushed on May 13, 2024
fanquake force-pushed on May 13, 2024
fanquake
commented at 12:45 PM on May 13, 2024:
member
Rebased on master.
Currently based on #30074 and #30078.
Dropped the commit related to --ld-path, and added a commit to remove binutils from the macOS Guix build env.
DrahtBot added the label CI failed on May 13, 2024
DrahtBot removed the label CI failed on May 13, 2024
fanquake referenced this in commit 7fcf4e9979 on May 14, 2024
fanquake force-pushed on May 14, 2024
fanquake referenced this in commit 695d80126f on May 15, 2024
fanquake force-pushed on May 15, 2024
fanquake marked this as ready for review on May 15, 2024
fanquake added the label DrahtBot Guix build requested on May 15, 2024
fanquake
commented at 4:20 AM on May 15, 2024:
member
Why are we setting this, or why are we dropping it for Darwin?
We no-longer need it given we aren't building Darwin tools. It's been disabled for all other hosts since Guix was introduced. I can dig up the history and post it here.
Ah, sorry, I misread. Had it backwards. It looked like it was being applied only to darwin before, but it was applied to everything but darwin before. Now darwin is no longer an exception.
Thanks.
theuni
commented at 6:39 PM on May 21, 2024:
member
DSYMUTIL does not get properly set in the config.site after these changes, and the wrong one ends up being found by our configure.
It's not clear to me if dsymutil ends up being used as part of our build at all. If so we should fix depends, if not we should remove it.
fanquake force-pushed on May 21, 2024
fanquake
commented at 8:20 PM on May 21, 2024:
member
It's not clear to me if dsymutil ends up being used as part of our build at all. If so we should fix depends, if not we should remove it.
I think it might actually be unused at this point, but also have a vauge memory of a Qt related failure, if it's missing.. Have pushed up a change to have it set properly for now.
in
depends/hosts/darwin.mk:52
in
7f736d395foutdated
Clang actually expects this all the time, so just dsymutil is correct in depends as well (so we can't copy the bin as llvm-dsymutil) (this was the qt related issue I had seen before).
DrahtBot added the label CI failed on May 22, 2024
depends: don't use -no_warning_for_no_symbols in macOS qt build
Not supported by llvm-ar / llvm-ranlib.
bab287d1ba
depends: swap cctools-x for llvm-x
Only build ld64 from cctools.
Disable adhoc codesigning, to avoid non-determinism.
437e908ebd
build: add lld into macOS build environment(s)c6a6b2d6fd
build: switch to using lld for macOS builds
Adjust the security check for:
ld64.lld: warning: Option `-allow_stack_execute' is not yet implemented.
ld64.lld: error: -fixup_chains is incompatible with -no_pie
and to account for the embedding of LLVMs version number.
4a0536c5d9
depends: remove cctools & libtapif836f7e9b3
guix: remove ZERO_AR_DATE export
LLD enables ZERO_AR_DATE by default, setting it to zero would enable
non-determinism, setting it to any other value is ignored.
See:
https://github.com/llvm/llvm-project/blob/main/lld/docs/MachO/ld64-vs-lld.rst.
9ec238d0f3
guix: use GUIX_LD_WRAPPER_DISABLE_RPATH for all HOSTS555fddf646
guix: drop binutils from macOS enve8c25e8a35
fanquake force-pushed on May 22, 2024
DrahtBot removed the label CI failed on May 22, 2024
TheCharlatan
commented at 9:25 AM on May 22, 2024:
contributor
theuni
commented at 7:04 PM on May 22, 2024:
member
I think it might actually be unused at this point, but also have a vauge memory of a Qt related failure, if it's missing.. Have pushed up a change to have it set properly for now.
Thanks, can confirm the correct one is picked up by our configure now.
Sjors
commented at 5:44 PM on May 23, 2024:
member
Tested e8c25e8a35e333e90514945c592557615641553f: the guix build, a local depends build and a local normal build on Intel macOS 14.5. Tested a normal build on macOS 13.6.7.
This is a metadata mirror of the GitHub repository
bitcoin/bitcoin.
This site is not affiliated with GitHub.
Content is generated from a GitHub metadata backup.
generated: 2026-04-22 15:14 UTC
This site is hosted by @0xB10C More mirrored repositories can be found on mirror.b10c.me