cmake: build failure on OSX 10.11 due to LegacySupport PortGroup

[dbl001 (dbl)]

$ sudo port upgrade outdated
Password:
--->  Computing dependencies for cmake
--->  Fetching archive for cmake
--->  Attempting to fetch cmake-3.14.0_0.darwin_15.x86_64.tbz2 from https://packages.macports.org/cmake
--->  Attempting to fetch cmake-3.14.0_0.darwin_15.x86_64.tbz2 from http://sea.us.packages.macports.org/macports/packages/cmake
--->  Attempting to fetch cmake-3.14.0_0.darwin_15.x86_64.tbz2 from http://kmq.jp.packages.macports.org/cmake
--->  Fetching distfiles for cmake
--->  Attempting to fetch cmake-3.14.0.tar.gz from https://distfiles.macports.org/cmake
--->  Verifying checksums for cmake                                             
--->  Extracting cmake
--->  Applying patches to cmake
--->  Configuring cmake
Error: Failed to configure cmake: configure failure: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_cmake/cmake/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets to report a bug.

[michaelld (Michael Dickens)]

I've also seen this issue on my OSX 10.11 build box. If you want a "quickie" workaround is to edit the cmake Portfile and comment out the line near the top that reads PortGroup legacysupport 1.0. Then clean cmake and try again & it should work (does for me). We're working on fixing the issue inside the Legacy Support PortGroup ... just not quite sure of what the right way to solve the issue is!

[michaelld (Michael Dickens)]

Tagging @kencu for some help with the LegacySupport PG here ...

[dbl001 (dbl)]

Thanks. Where is the ‘cmake Portfile’ located? I couldn’t find it under: /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_cmake/cmake/work/cmake-3.14.0

[michaelld (Michael Dickens)]

Try port dir cmake to get to the directory.

[mf2k (Frank Schima)]

The Milestone field is for use by Macports team members only, please do not set it.

[dbl001 (dbl)]

The work-around E.g. Commenting out:

#PortGroup           legacy support 1.0, in

/opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/devel/cmake

worked.

[kencu (Ken)]

Michael did some analysis on this a few weeks ago -- it has to do with 10.11 using the 10.12 SDK:

On (at least) OSX 10.11, if -both- of the following flags are used at the same time:

-mmacosx-version-min=10.11

-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk

... then __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ == 101100 -but- "clockid_t" is defined by time.h in the SDK and thus the build errors out when using the Legacy support project's headers.

If just the "-isysroot" flag is used, then __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ == 101200 as desired and things work correctly. Likewise if just the -mmacosx-version-min=10.11 flag is used (but no specific SDK), then __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ == 101100 as desired and the correct headers are used that do not contain "clockid_t" and things work correctly. It's just this one condition that fails, which of course is what CMake sets by default :)

If I do:

clang++ -x c++ -mmacosx-version-min=10.11 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk -std=gnu++11 -dM -E - < /dev/null

and the like varying the "min" and "sdk", then when "-mmacosx-version-min=10.11" is used I can vary the SDK but the macros output are identical. If I remove the "-mmacosx-version-min=10.11" then I get the different macros for the different SDKs as desired.

The build error seems to be:

90 /opt/local/include/LegacySupport/time.h:44:13: error: typedef redefinition with different types ('int' vs 'enum clockid_t')
91	typedef int clockid_t;
92	            ^
93	/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/time.h:171:3: note: previous definition is here
94	} clockid_t;
95	 

so if we make sure we use exactly the same typedefs in time.h as used in the 10.12 SDK I would think we should be OK.

[kencu (Ken)]

Or we just restrict the legacysupport PG use in cmake to systems < 10.10 and workaround it like that, in the immediate term :>

[kencu (Ken)]

Chris, what do think about a way past this? This is your file, originally...

[cjones051073 (Chris Jones)]

I don't like the idea of restricting the legacy support PG in cmake to < 10.10 as at some point in the future we might need something from it in 10.10+ systems.

We need to update the legacy support time.h to define clockid_t the same as the system in use, somehow..

[cjones051073 (Chris Jones)]

b.t.w. Ken, it would be very useful if you could cook up some sort of test to add to the legacy support package for this issue, so we can test it there rather than via a MP make port, which is way more convoluted...

[cjones051073 (Chris Jones)]

maybe we should just update the legacy method in the package to use an enum here, instead of int...

[cjones051073 (Chris Jones)]

i.e., based on what is in 10.12+ time.h, something like

typedef enum {
_CLOCK_REALTIME = 0,
#ifndef CLOCK_REALTIME
# define CLOCK_REALTIME _CLOCK_REALTIME
#endif
_CLOCK_MONOTONIC = 6
#ifndef CLOCK_MONOTONIC
# define CLOCK_MONOTONIC _CLOCK_MONOTONIC
#endif
} clockid_t;

[cjones051073 (Chris Jones)]

See ​https://github.com/macports/macports-legacy-support/pull/19

[michaelld (Michael Dickens)]

Has duplicate #58202

[macuserguru]

workaround - how could I exclude 'cmake' from the 'port upgrade outdated' list?

I want to upgrade the rest.

[macuserguru]

This works:

sudo port upgrade outdated and not cmake

similar to

sudo port uninstall inactive and not ''portname''

​https://guide.macports.org/chunked/using.common-tasks.html

[cjones051073 (Chris Jones)]

FWIW, I just tried reproducing this on my OSX10.11 VM, and was not able to. In the end I suspect the reason is I have Xcode 7 installed, whereas the OP here is using Xcode 8 on OSX10.11. I think its that specific combination of versions that causes the problem.

[macuserguru]

MBP late 2008 / Mac OSX 10.11.6 (15G22010) / Xcode 8.2.1 / port version 2.5.4

[cjones051073 (Chris Jones)]

yeah, the relevant info on your system is at the start of the build log ;)

[cjones051073 (Chris Jones)]

In my opinion, from MacPorts the advice should be if you are running OSX10.11, to stick with Xcode 7. Xcode 8 does not have the 10.11 SDK, only 10.12, which is the trigger for all the issues here.

That is not to say we should find a way to work around this, if we can. Just the advice should be to avoid it in the first place ;)

[michaelld (Michael Dickens)]

It's difficult to ignore the App Store's insistence that updates are available to Xcode & not do them ...

One option in the cmake Portfile would be to check the OS & Xcode versions && if 10.11 && 8 then do not include the legacy PG.

Chris: FYI I'm about to try out your legacy fix to see if it works.

[michaelld (Michael Dickens)]

According to < ​https://trac.macports.org/wiki/XcodeVersionInfo >, 10.11 can use any Xcode 7.2.1 or 7.3.1 -- which I'm guessing do not correctly define clock_gettime (etc) -- or Xcode 8.0.0 to 8.2.1 -- which I'm guessing do include those routines. My install has 8.2.1, as do I think all of the folks here having the issue ... hence I can't actually test whether Xcode 8.0.0 provides this feature or not; just a guess.

Chris: Could you make a copy of your VM & update the Xcode to 8.0.0 & see if the SDK provides clock_gettime in the time.h header? That would probably be the fastest way to confirm. Then you can delete your new VM or not as you see fit.

[cjones051073 (Chris Jones)]

Sure, I can do that, but I am fairly certain the issue is specific to using xcode 8 on 10.11 (or more precisely, using the 10.12 sdk that xcode 8 ships with, on 10.11).

[michaelld (Michael Dickens)]

In 5eba5a27c81f2b508944bcee3216f753ec6c4c45/macports-ports (master):

cmake: temporary fix for LegacySupport issue

Hopefully addresses < #58199 > and < #58200 >.

Just temporary while we figure out a better way to handle this specific circumstance within the LegacySupport headers.

We believe that Xcode 8+ provides "clock_gettime"; we know this is true for Xcode 8.2.1, and we know that Xcode 7.2.1. does not provide this feature. legacysupport is used for 10.11 just for this specific feature, so use it only if OSX <= 10.11 && Xcode < 8.

See also < ​https://trac.macports.org/wiki/XcodeVersionInfo > for the various combinations of OSX and Xcode versions.

[cjones051073 (Chris Jones)]

Replying to michaelld:

It's difficult to ignore the App Store's insistence that updates are available to Xcode & not do them ...

I checked that. My vm 10.11 does Not offer me the update to xcode 8 in the app store.....

One option in the cmake Portfile would be to check the OS & Xcode versions && if 10.11 && 8 then do not include the legacy PG.

Chris: FYI I'm about to try out your legacy fix to see if it works.

[michaelld (Michael Dickens)]

For folks with this issue: I just pushed a temporary fix that should work for you. Please update your ports & try again & please do comment back here success or failure ... and if the latter please attach the build logfile for us to review.

[michaelld (Michael Dickens)]

Hmmm ... I think you can download Xcode 8.0.0 directly & install it ... just bypass the App Store?

[cjones051073 (Chris Jones)]

I think the thing we need to do is update the legacy support time.h to (somehow...) detect when a 10.12 sdk is being used, on 10.11, and then skip defining the enum, but keep the implementation of the two methods. So the question is is there some sort of define we can look for, to check the sdk version being used ?

[deldotvee]

Yes this fix has worked for me. My Xcode is 8.2.1

[macuserguru]

Now it works after an selfupdate

$ port outdated
The following installed ports are outdated:
cmake                          3.13.4_0 < 3.14.0_0       
python34                       3.4.9_1 < 3.4.10_0        
bash-3.2$ sudo /opt/local/bin/port upgrade outdated
--->  Computing dependencies for cmake
--->  Fetching archive for cmake
--->  Attempting to fetch cmake-3.14.0_0.darwin_15.x86_64.tbz2 from https://packages.macports.org/cmake
--->  Attempting to fetch cmake-3.14.0_0.darwin_15.x86_64.tbz2.rmd160 from https://packages.macports.org/cmake
--->  Installing cmake @3.14.0_0
--->  Cleaning cmake
--->  Computing dependencies for cmake
--->  Deactivating cmake @3.13.4_0
--->  Cleaning cmake
--->  Activating cmake @3.14.0_0
--->  Cleaning cmake
.........

[macuserguru]

Looks like a finished compiled package.

[michaelld (Michael Dickens)]

Great! Thanks for reporting back your successes. We'll figure out a better way to do this off-ticket & check/verify on our various systems before committing; the change will be transparent to folks who might have this very specific OS / Xcode combination.

[michaelld (Michael Dickens)]

Closing as fixed.

Chris: Let's move any discussion of this issue to the Legacy Support PR handling clock_gettime.