[Upstream] [Depends] Update macOS cross-compiling toolchain #136
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Co-Authored-By: Carl Dong <accounts@carldong.me>
This also removes some now-unnecessary cctools hacks. Co-Authored-By: Cory Fields <cory-nospam-@coryfields.com>
This also removes the obsolete mlinker-version option Co-Authored-By: Cory Fields <cory-nospam-@coryfields.com>
Co-Authored-By: Carl Dong <accounts@carldong.me>
Previously, we did not include the macOS SDK libc++ headers in our SDK creation process and instead used whichever libc++ headers shipped with the clang package we downloaded in depends. This change adds a script (which works on both GNU/Linux and macOS) to correctly generate the macOS SDK including the libc++ headers. This can be thought of as a simplified rewrite of tpoechtrager's script: https://github.com/tpoechtrager/osxcross/blob/d3392f4eae78f3fa3f1fd065fa423f2712825102/tools/gen_sdk_package.sh The location within the SDK where we place the libc++ headers is chosen such that clang's search path detection logic for sysroots would pick up the headers properly. We also document this change.
Now that we include the macOS SDK libc++ headers in our macOS SDK tarball, we no longer need this hack to use the libc++ from our pinned clang.
clang 6.0.1 -> 8.0.0 cctools 921 -> 949.0.1 ld64 409.12 -> 530
This gets us a newer SDK with c++17 support and retains 10.12 back-compat. Co-Authored-By: Carl Dong <contact@carldong.me>
Without this clang fails to add any newly-added linker features. Removing this in PIVX-Project/PIVX@ca5055a was likely a regression. See bitcoin/bitcoin#19240 (comment) for more discussion.
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.
This should be caught by the differing clang --version outputs, but because we haven't yet extracted our pinned clang, the system one is actually used for the version check. That's not a problem because bumping our pinned clang will cause a rebuild of everything anyway.
For depends builds this was fixed by Fuzzbawls/PIVX@fbcfcf6, 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.
Note that this does not _enable_ lto by default in any way, only hooks up the machinery for -flto to work correctly. enable-lto-support is explicitly used for pinned-clang because we know it works. It is neither enabled nor disabled in the external clang case so that it can be auto-detected.
tpoechtrager/cctools-port#85 was merged upstream, which fixes lto detection for external clang with some Linux Distro's including Ubuntu.
native_ds_store now takes advantage of Pythons ability to decode binary plists (since 3.4), so we can drop its biplist dependency. The call to biplist.Data() in custom_dsstore doesn't seem to do anything, and from what I can tell can just be removed.
See https://docs.python.org/3/library/plistlib.html. The new API was added in 3.4 and old removed in 3.9.
Aplies a patch to Qt that fixes the non-determinism by modifying Qt. The source of the non-determinism is how LLVM 8 optimizes qt_intersect_spans when compiling. The particular optimization that seems to be causing the problems is that a temp variable is being added for spans->y. For some reason, when it does this, it chooses different instructions to use when making that variable. We bypass this problem by patching qt_intersect_spans to always make and use this local variable.
lopeed
approved these changes
Oct 31, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
from https://github.com/PIVX-Project/PIVX/pull/2272/commits
Part of a series of updates to the macOC toolchain/deployment