Opened 6 years ago

Closed 6 years ago

#58199 closed defect (fixed)

cmake: build failure on OSX 10.11 due to LegacySupport PortGroup

Reported by: dbl001 (dbl) Owned by: michaelld (Michael Dickens)
Priority: Normal Milestone:
Component: ports Version: 2.5.4
Keywords: Cc: kencu (Ken), cjones051073 (Chris Jones), thetrial (alabay), macuserguru
Port: cmake

Description

$ 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.

Attachments (3)

CMakeOutput.log (56.1 KB) - added by dbl001 (dbl) 6 years ago.
main.log (227.0 KB) - added by dbl001 (dbl) 6 years ago.
CMakeError.log (10.4 KB) - added by dbl001 (dbl) 6 years ago.

Download all attachments as: .zip

Change History (43)

Changed 6 years ago by dbl001 (dbl)

Attachment: CMakeOutput.log added

Changed 6 years ago by dbl001 (dbl)

Attachment: main.log added

Changed 6 years ago by dbl001 (dbl)

Attachment: CMakeError.log added

comment:1 Changed 6 years ago by dbl001 (dbl)

Keywords: cmake added
Port: cmake-3.1.4 added; make-3.1.4 removed

comment:2 Changed 6 years ago by michaelld (Michael Dickens)

Owner: set to michaelld
Status: newassigned
Summary: Error: Failed to configure cmake: configure failure: command execution failedcmake: build failure on OSX 10.11 due to LegacySupport PortGroup

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!

comment:3 Changed 6 years ago by michaelld (Michael Dickens)

Port: cmake cmake-devel added; cmake-3.1.4 removed

comment:4 Changed 6 years ago by michaelld (Michael Dickens)

Cc: kencu added

comment:5 Changed 6 years ago by michaelld (Michael Dickens)

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

comment:6 Changed 6 years ago by 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

comment:7 Changed 6 years ago by michaelld (Michael Dickens)

Try port dir cmake to get to the directory.

comment:8 Changed 6 years ago by mf2k (Frank Schima)

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

comment:9 Changed 6 years ago by mf2k (Frank Schima)

Keywords: cmake removed
Milestone: MacPorts 2.6.0
Port: cmake-devel removed

comment:10 Changed 6 years ago by 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.

comment:11 Changed 6 years ago by 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.

Last edited 6 years ago by kencu (Ken) (previous) (diff)

comment:12 Changed 6 years ago by 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 :>

comment:13 Changed 6 years ago by kencu (Ken)

Cc: cjones051073 added

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

comment:14 Changed 6 years ago by 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..

comment:15 Changed 6 years ago by 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...

comment:16 Changed 6 years ago by cjones051073 (Chris Jones)

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

comment:17 Changed 6 years ago by 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;

Last edited 6 years ago by cjones051073 (Chris Jones) (previous) (diff)

comment:19 Changed 6 years ago by thetrial (alabay)

Cc: thetrial added

comment:20 Changed 6 years ago by macuserguru

Cc: macuserguru added

comment:21 Changed 6 years ago by michaelld (Michael Dickens)

Has duplicate #58202

comment:22 Changed 6 years ago by macuserguru

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

I want to upgrade the rest.

Last edited 6 years ago by macuserguru (previous) (diff)

comment:23 Changed 6 years ago by 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

Last edited 6 years ago by macuserguru (previous) (diff)

comment:24 Changed 6 years ago by 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.

comment:25 Changed 6 years ago by macuserguru

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

comment:26 Changed 6 years ago by cjones051073 (Chris Jones)

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

comment:27 Changed 6 years ago by 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 ;)

comment:28 Changed 6 years ago by 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.

comment:29 Changed 6 years ago by 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.

comment:30 Changed 6 years ago by 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).

comment:31 Changed 6 years ago by 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.

comment:32 in reply to:  28 Changed 6 years ago by 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.

comment:33 Changed 6 years ago by 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.

comment:34 Changed 6 years ago by michaelld (Michael Dickens)

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

comment:35 Changed 6 years ago by 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 ?

Last edited 6 years ago by cjones051073 (Chris Jones) (previous) (diff)

comment:36 Changed 6 years ago by deldotvee

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

comment:37 Changed 6 years ago by 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
.........

comment:38 Changed 6 years ago by macuserguru

Looks like a finished compiled package.

comment:39 Changed 6 years ago by 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.

comment:40 Changed 6 years ago by michaelld (Michael Dickens)

Resolution: fixed
Status: assignedclosed

Closing as fixed.

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

Note: See TracTickets for help on using tickets.