| Summary: | cmake-3.13.5 fails to build during darwin prefix bootstrap | ||
|---|---|---|---|
| Product: | Gentoo/Alt | Reporter: | Jacob Floyd <cognifloyd+gentoobugs> |
| Component: | Prefix Support | Assignee: | Gentoo Prefix <prefix> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | ||
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | OS X | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=757513 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 755644 | ||
| Attachments: |
Modified prefix-dirs patch for cmake-3.13
Modified prefix-dirs patch for cmake 3.16+ updated cmake-3.13.5.ebuild |
||
Created attachment 675640 [details]
Modified prefix-dirs patch for cmake-3.13
This is the modified patch that adds the SDK path to the framework search path in cmake. It should allow cmake to find frameworks when building other applications.
Created attachment 675643 [details]
Modified prefix-dirs patch for cmake 3.16+
This is the prefix-dirs patch used in all the newer cmake ebuilds. I made the same change to it to add the SDK Frameworks search path.
Created attachment 675646 [details] updated cmake-3.13.5.ebuild This includes these lines in cmake_src_bootstrap (which is called in src_prepare if cmake is not already installed): > local sdk_frameworks="${EPREFIX}/MacOSX.sdk/System/Library/Frameworks" > if [[ -d "${sdk_frameworks}" ]]; then > # ensure frameworks are found for darwin prefix > append-cflags $(test-flags-CC "-F${sdk_frameworks}") > append-cxxflags $(test-flags-CXX "-F${sdk_frameworks}") > fi So, this is a minor change that should not impact anyone except those that are building on Darwin. Is a revbump required? I think we should fix 3.13 first, and then deal with 3.16+ in conjunction with bug#757513 Closing in favor of the changes in bug#757513 *** This bug has been marked as a duplicate of bug 757513 *** |
During prefix bootstrap, stage2, bootstrapping cmake (during src_prepare) fails because it needs access to the CoreFoundation framework headers to build on OS X. Hacking the bootstrap make file can get past the bootstrap step, but then the boostrapped cmake fails to build itself because, again, it needs access to some frameworks. Reproducible: Always Steps to Reproduce: 1. bootstrap-prefix.sh 2. a few hacks to get through stage1 3. during stage2, it builds the llvm_deps including cmake. 4. during cmake src_prepare, the ebuild bootstraps cmake. Actual Results: bootstrap and subsequent phases of build fail due to missing framework headers. Expected Results: Finish emerging There are 3 levels that need to get the framework path: - src_prepare -> build the cmake boostrap binary - src_compile -> cmake bootstrap binary building cmake itself - once installed, cmake needs the path to build other things For both GCC and clang based darwin prefix installations, the prefix configured SDK (a symlink created during the bootstrap-prefix.sh run) is available at ${EPREFIX}/MacOSX.sdk. I tried adjusting a variety of env vars from within bootstrap-prefix.sh, but one or more layers did not respond to those vars. The second layer, where cmake is bootstrapping itself, proved particularly difficult to fix without adjusting something within the ebuild. The final solution consists of a change in the ebuild (append-cflags and append-cxxflags during src_prepare/bootstrap) to fix the first two phases, and a modified patch to adjust to the new SDK location in prefix builds. These changes will also need to be made to other cmake versions, probably as part of bug#757313.