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)
Change History (43)
Changed 6 years ago by dbl001 (dbl)
Attachment: | CMakeOutput.log added |
---|
Changed 6 years ago by dbl001 (dbl)
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: | new → assigned |
Summary: | Error: Failed to configure cmake: configure failure: command execution failed → cmake: build failure on OSX 10.11 due to LegacySupport PortGroup |
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.
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;
comment:18 Changed 6 years ago by cjones051073 (Chris Jones)
comment:19 Changed 6 years ago by thetrial (alabay)
Cc: | thetrial added |
---|
comment:20 Changed 6 years ago by macuserguru
Cc: | macuserguru added |
---|
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.
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''
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 follow-up: 32 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)
comment:32 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 ?
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: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: | assigned → closed |
Closing as fixed.
Chris: Let's move any discussion of this issue to the Legacy Support PR handling clock_gettime
.
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
. Thenclean 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!