depends: Eliminate hard dependency on Ubuntu-ABI specific clang #17099
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
If you need people to re-generate the MacOSX SDK, please document it well and make sure there's a way that people without Macs can do it (I don't have access to a Mac anymore, for one). Might want to combine it with the version upgrade. |
45907dd to
4040e5e
Compare
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>
For the longest time we have downloaded an Ubuntu ABI-specific clang and just used it. No longer will we be subject to the tyranny of Ubuntu's ABI!
We manually put the toolchain and binutils into the same path in native_cctools, this is unintuitive. Since we effectively decouple our toolchain and binutils in this patchset, the make variables should reflect this as well. The $(toolchain_path) prefix is removed in the next commit. They are separate so I can do this scripted-diff. -BEGIN VERIFY SCRIPT- find depends -type f -print0 | xargs -0 sed -i "s/_native_toolchain/_native_binutils/g" find depends -type f -print0 | xargs -0 sed -i "s/toolchain_path/binutils_path/g" -END VERIFY SCRIPT-
If we do end up building a compiler inside depends in the future, we can just add a separate compiler_path prefix and use it here. See the previous commit for more details.
Previously, we did not include the libc++ headers in our SDK creation, now we can use tpoechtrager's script to correctly do that. The gen_sdk_package.sh is taken from https://github.com/tpoechtrager/osxcross/blob/d3392f4eae78f3fa3f1fd065fa423f2712825102/tools/gen_sdk_package.sh We also document this change.
4040e5e to
a0fefee
Compare
|
Updated documentation in 1250d22 and a0fefee, would like some advice on whether it's alright to just copy the script over from https://github.com/tpoechtrager/osxcross/blob/d3392f4eae78f3fa3f1fd065fa423f2712825102/tools/gen_sdk_package.sh in a0fefee |
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ConflictsReviewers, this pull request conflicts with the following ones:
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. |
|
Is it really required to first bump clang to a more recent version and then in the next commit remove the hardcoded clang? Wouldn't it be more straightforward to just remove the hardcoded clang? |
14 tasks
9ef424c to
2becb91
Compare
484d480 to
a0fefee
Compare
fanquake
added a commit
that referenced
this pull request
Jul 16, 2020
de4fedb depends: Add documentation for FORCE_USE_SYSTEM_CLANG make flag (Carl Dong) fe98999 depends: Reformat make options as definition list (Carl Dong) 60c55b1 depends: Add justifications for macOS clang flags (Carl Dong) 6b8e497 depends: specify libc++ header location for darwin (Cory Fields) 156b604 depends: force a new host id string if FORCE_USE_SYSTEM_CLANG is in use (Cory Fields) c9c572a depends: Allow building with system clang (Carl Dong) e6e5c8d depends: Decouple toolchain + binutils (Carl Dong) Pull request description: This replaces: #17099 ----- This patchset allows us to force depends to use system clang. Previously, #17099 removes our dependency on a specific clang we download from llvm.org, but theuni pointed out that since OSX builds are only ever built with a version of clang that is chosen and "blessed" by Apple, it is more likely that the user will encounter problems if they use their system clang. This patchset forces the user to set `FORCE_USE_SYSTEM_CLANG=1` in order to use their system clang (when they know what they're doing) ACKs for top commit: theuni: ACK de4fedb. Tree-SHA512: 8774121e035f90c27030bcce06e1b79f7729b5e17802c718e49652ab06e19780632db974df47423c1d1b04f1ab1b7a763554fb922fec05d1cd6445b26578be1d
sidhujag
pushed a commit
to syscoin/syscoin
that referenced
this pull request
Jul 18, 2020
de4fedb depends: Add documentation for FORCE_USE_SYSTEM_CLANG make flag (Carl Dong) fe98999 depends: Reformat make options as definition list (Carl Dong) 60c55b1 depends: Add justifications for macOS clang flags (Carl Dong) 6b8e497 depends: specify libc++ header location for darwin (Cory Fields) 156b604 depends: force a new host id string if FORCE_USE_SYSTEM_CLANG is in use (Cory Fields) c9c572a depends: Allow building with system clang (Carl Dong) e6e5c8d depends: Decouple toolchain + binutils (Carl Dong) Pull request description: This replaces: bitcoin#17099 ----- This patchset allows us to force depends to use system clang. Previously, bitcoin#17099 removes our dependency on a specific clang we download from llvm.org, but theuni pointed out that since OSX builds are only ever built with a version of clang that is chosen and "blessed" by Apple, it is more likely that the user will encounter problems if they use their system clang. This patchset forces the user to set `FORCE_USE_SYSTEM_CLANG=1` in order to use their system clang (when they know what they're doing) ACKs for top commit: theuni: ACK de4fedb. Tree-SHA512: 8774121e035f90c27030bcce06e1b79f7729b5e17802c718e49652ab06e19780632db974df47423c1d1b04f1ab1b7a763554fb922fec05d1cd6445b26578be1d
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
This is based on:
We previously just downloaded a clang binary from llvm.org. However, I think clang is mature and mainstream enough for us to use the system one. The Gitian descriptors have also been changed accordingly (and work).
MarcoFalke if the Gitian Builds fail for this one, it's because:
We DO need to fix our docs for generating macOS SDKs... Previously we just tarred up
MacOSX10.14.sdk, but we also need to copy over the headers as done here: https://github.com/tpoechtrager/osxcross/blob/d3392f4eae78f3fa3f1fd065fa423f2712825102/tools/gen_sdk_package.sh#L183-L188In fact, we should probably just subtree tpoechtrager's SDK generation scripts.