Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 757516 - cmake-3.13.5 fails to build during darwin prefix bootstrap
Summary: cmake-3.13.5 fails to build during darwin prefix bootstrap
Status: RESOLVED DUPLICATE of bug 757513
Alias: None
Product: Gentoo/Alt
Classification: Unclassified
Component: Prefix Support (show other bugs)
Hardware: All OS X
: Normal normal (vote)
Assignee: Gentoo Prefix
Depends on:
Blocks: 755644
  Show dependency tree
Reported: 2020-11-28 23:48 UTC by Jacob Floyd
Modified: 2020-11-30 00:49 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---

Modified prefix-dirs patch for cmake-3.13 (cmake-3.13.4-prefix-dirs.patch,4.20 KB, application/mbox)
2020-11-28 23:51 UTC, Jacob Floyd
Modified prefix-dirs patch for cmake 3.16+ (cmake-3.14.0_rc3-prefix-dirs.patch,4.64 KB, application/mbox)
2020-11-28 23:56 UTC, Jacob Floyd
updated cmake-3.13.5.ebuild (cmake-3.13.5.ebuild,6.39 KB, text/plain)
2020-11-29 00:06 UTC, Jacob Floyd

Note You need to log in before you can comment on or make changes to this bug.
Description Jacob Floyd 2020-11-28 23:48:19 UTC
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:
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 run) is available at ${EPREFIX}/MacOSX.sdk.

I tried adjusting a variety of env vars from within, 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.
Comment 1 Jacob Floyd 2020-11-28 23:51:12 UTC
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.
Comment 2 Jacob Floyd 2020-11-28 23:56:33 UTC
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.
Comment 3 Jacob Floyd 2020-11-29 00:06:43 UTC
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?
Comment 4 Jacob Floyd 2020-11-29 00:22:27 UTC
I think we should fix 3.13 first, and then deal with 3.16+ in conjunction with bug#757513
Comment 5 Jacob Floyd 2020-11-30 00:49:48 UTC
Closing in favor of the changes in bug#757513

*** This bug has been marked as a duplicate of bug 757513 ***