update cmake to version 3.8.1

[dimpase]

it has been released, and is the current stable version.

here is the tarball: ​https://cmake.org/files/v3.8/cmake-3.8.1.tar.gz

[dimpase]

with SAGE_CHECK=yes I get, on Gentoo Linux,

[cmake-3.8.1] The following tests FAILED:
[cmake-3.8.1] 	409 - GTK2Components.gtk (Failed)
[cmake-3.8.1] 	419 - GTK2Targets.pangocairo (Failed)
[cmake-3.8.1] 	420 - GTK2Targets.pangoxft (Failed)
[cmake-3.8.1] 	421 - GTK2Targets.pangoft2 (Failed)
[cmake-3.8.1] 	422 - GTK2Targets.gdk (Failed)
[cmake-3.8.1] 	423 - GTK2Targets.gtk (Failed)
[cmake-3.8.1] Errors while running CTest

which probably can be ignored, as this is something GTK-specific?

[dimpase]

New commits:

​addf5a7

cmake update to 3.8.1

[fbissey]

Optional packages should pass their test suite. This is curious, it obviously picked up stuff from your system, why is it then failing? Thanks for the branch, I'll have a look here.

[dimpase]

No idea. I can only say that on my system I have cmake version 3.7.2, and it fails, with some weird error, to build ​http://hg.mrzv.org/Dionysus/ that I can build with cmake 3.8.1.

Perhaps cmake should be built with some correct options to avoid this testing error?

[fbissey]

I think the tests are slightly broken... I have more of them

[cmake-3.8.1] The following tests FAILED:
[cmake-3.8.1]   136 - Qt5Autogen (Failed)
[cmake-3.8.1]   138 - Qt4Autogen (Failed)
[cmake-3.8.1]   140 - Qt4Targets (Failed)
[cmake-3.8.1]   142 - Qt4And5AutomocReverse (Failed)
[cmake-3.8.1]   417 - GTK2Components.gtk (Failed)
[cmake-3.8.1]   425 - GTK2Targets.cairo (Failed)
[cmake-3.8.1]   427 - GTK2Targets.pangocairo (Failed)
[cmake-3.8.1]   428 - GTK2Targets.pangoxft (Failed)
[cmake-3.8.1]   429 - GTK2Targets.pangoft2 (Failed)
[cmake-3.8.1]   430 - GTK2Targets.gdk (Failed)
[cmake-3.8.1]   431 - GTK2Targets.gtk (Failed)
[cmake-3.8.1] Errors while running CTest

but I think they all boil down to the linking errors with libpng and libharfbuzz, messages like

/usr/lib64/libpng16.so.16: undefined reference to `inflateValidate@ZLIB_1.2.9'

and

/usr/lib64/libharfbuzz.so.0: undefined reference to `FT_Get_Var_Blend_Coordinates'

Why do we get those? Very simple, the version of zlib and freetype in the sage build tree are older then the one on the system. But enforced runpath in sage means that the version in $SAGE_LOCAL/lib/ are the one being loaded instead of the system one.

The upgrade to zlib-1.2.11 will bring relief to the libpng linking. freetype 2.7.1 is the current stable in a gentoo system, 2.6.3 is the one in sage.

We could somewhat solve the the problem by upping zlib (why isn't this already merged?) and freetype but that won't prevent a recurrence down the line when some dependency gets out of sync again between system tree and sage tree.

I'll think about what to do next. Suppressing tests will just result in a n ever growing list.

[dimpase]

I get exactly the same errors with 3.8.0, so this is probably either my system, or it a "feature" of cmake---for they cannot use autoconf for ideological reasons, I guess :-)

[dimpase]

in my case it's linking errors like

422: /usr/lib64/libharfbuzz.so.0: undefined reference to `FT_Get_Var_Blend_Coor
dinates'

• no idea what this harfbuzz is all about, some hardcore GTK stuff I guess.

[fbissey]

It is a bit more than that. IT find QT/GTK on the system - we don't prevent that, and historically we don't want to. The problem is that the qt and gtk library used have dependency on libraries that are now conflicting with the sage installed ones.

I guess I didn't try on Gentoo when I was working on 3.8.0 - I focused on OS X leaving the linux stuff to other.

autoconf would marginally help I guess, in that you wouldn't test for stuff if you have configured them out. That would mean no automagic in configure and us explicitly disabling it. Here we may have automagic on gtk - possibly decoupled between configuration and tests.

Checking things....

[fbissey]

Yes that's what I thought. No way of controlling gtk stuff from the base of the build system.

In any case even if I suppress the tests, it means that anyone wanting to build a gtk/qt program on top of sage using cmake is at risk of getting something broken because of library conflict between system and sage libraries. autoconf is not immune to the problem either, you are likely to face exactly the same problems.

[fbissey]

Another point: the problem here wouldn't happen if zlib and freetype had incremented the soname for their libraries. The libraries are obviously backward compatible but not forward compatible which is killing us here.

[fbissey]

All tests suppressed in the attached branch.

Other idea way out there: that kind of conflict is not a first. This is a consequence of having runpath set. runpath have been selected as a cleaner way to deal with selecting the right libraries from the sage tree over the system ones. We used to have {DY,}LD_LIBRARY_PATH set and now we do runpath. LD_LIBRARY_PATH can still be used to over-rule runpath but we have moved from putting the path information in an environment variable loaded at runtime to putting it in the binary itself (executable and dynamic libraries).

It guarantee we use the sage tree over anything else but it still doesn't prevent conflict as seen above.

To totally avoid conflict you need to go one step further: brand the libraries

What do I mean by that? Take zlib, it installs the following library objects

lrwxrwxrwx 1 fbissey fbissey   13 May 11 10:54 local/lib/libz.so -> libz.so.1.2.8
lrwxrwxrwx 1 fbissey fbissey   13 May 11 10:54 local/lib/libz.so.1 -> libz.so.1.2.8
-rwxr-xr-x 1 fbissey fbissey 111K May 11 10:54 local/lib/libz.so.1.2.8

and we have

fbissey@moonloop ~/sandbox/git-fork/sage $ readelf -d local/lib/libz.so.1.2.8

Dynamic section at offset 0x18dd0 contains 28 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000000e (SONAME)             Library soname: [libz.so.1]
 0x000000000000001d (RUNPATH)            Library runpath: [/home/fbissey/sandbox/git-fork/sage/local/lib]

I suggest we change the soname to libz.so.1_sage (or something similar) and install

lrwxrwxrwx 1 fbissey fbissey   13 May 11 10:54 local/lib/libz.so -> libz.so.1.2.8
lrwxrwxrwx 1 fbissey fbissey   13 May 11 10:54 local/lib/libz.so.1_sage -> libz.so.1.2.8
-rwxr-xr-x 1 fbissey fbissey 111K May 11 10:54 local/lib/libz.so.1.2.8

It may look strange but with the right soname it is sufficient. That would be a lot of work, but I believe this is the only true way to avoid any conflict: runpath+branding.

The install_name mechanism on OS X is slightly better in that regard. If you don't mess up with it, the library name recorded in MACH-O object is fully qualified (full path) rather than just an object name. The fully qualified path can still be over-ridden by application of a runpath in situ or by environment variable.

---

New commits:

​3251968

supress tests failing due mix match of libraries between host and sage

[dimpase]

I wonder how this would play out on cygwin. Potentially it might help avoid DLL clashes there, if it flies at all.

[dimpase]

with your branch, it works on Linux, while on FreeBSD I get

[cmake-3.8.1] The following tests FAILED:
[cmake-3.8.1]   298 - RunCMake.GNUInstallDirs (Failed)
[cmake-3.8.1] Errors while running CTest

log attached. Something to do with stderr...

[fbissey]

Extremely stupid. Should be an upstream issue.

Expected

expect-err> CMAKE_INSTALL_MANDIR='share/man'

got

actual-err> CMAKE_INSTALL_MANDIR='man'

and there is another entry relating to MANDIR that is incorrect in the output. And this is repeated over several subtests. I think I could make a patch for that, rather than suppressing it.

[fbissey]

This is now ​https://gitlab.kitware.com/cmake/cmake/issues/16887

[dimpase]

Thanks. I was unable to spot where the differences there are. Perhaps it's about GNUInstallDirs vs nonGNU (why would they expect FreeBSD to adhere to GNU standards?)

[fbissey]

Replying to dimpase:

Thanks. I was unable to spot where the differences there are. Perhaps it's about GNUInstallDirs vs nonGNU (why would they expect FreeBSD to adhere to GNU standards?)

In that regards, it may be misleading. While the module is called GNUInstallDirs it clearly defines stuff in BSD's case, the fact that it is different from linux is the root cause of the problem. The person who wrote the test didn't realise that it wouldn't pass on *BSD [although the test has a bizarre clause for OpenBSD that I haven't seen anywhere else]. The test stresses the output of the CMake module found at Modules/GNUInstallDirs.cmake in the cmake sources and it contains the following

if(CMAKE_SYSTEM_NAME MATCHES "^(.*BSD|DragonFly)$")
  _GNUInstallDirs_cache_path_fallback(CMAKE_INSTALL_INFODIR "info"
    "Info documentation (info)")
  _GNUInstallDirs_cache_path_fallback(CMAKE_INSTALL_MANDIR "man"
    "Man documentation (man)")
else()
  _GNUInstallDirs_cache_path_fallback(CMAKE_INSTALL_INFODIR "${CMAKE_INSTALL_DATAROOTDIR}/info"
    "Info documentation (DATAROOTDIR/info)")
  _GNUInstallDirs_cache_path_fallback(CMAKE_INSTALL_MANDIR "${CMAKE_INSTALL_DATAROOTDIR}/man"
    "Man documentation (DATAROOTDIR/man)")
endif()

There is only one other CMAKE_SYSTEM_NAME variation and the test deals with it properly in all cases I think.

[fbissey]

OK, so I can technically make this pass on freeBSD with an easy patch to the current test. Upstream doesn't like that approach, to them the test should be made platform specific. Right now, I don't know how to do that.

[fbissey]

What does UNAME get set to on freeBSD? I could skip the test based on OS.

[dimpase]

$ uname -a
FreeBSD dimpase-bsd.x.y.z 11.0-RELEASE-p1 FreeBSD 11.0-RELEASE-p1 #0 r306420: Thu Sep 29 01:43:23 UTC 2016     root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64

$ uname
FreeBSD

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​43aec08

make an exception for freeBSD

[fbissey]

Alright! Can you test with that last commit please.

[dimpase]

see failing test 298 (2nd try)

[dimpase]

nope, still the same test that is failing

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​8fbe406

make exception for correct OS, FreeBSD not Darwin.

[fbissey]

I am a dummy. I copy pasted from somewhere but forgot to change the essential bit identifying freeBSD. Should work now.

[dimpase]

All the selftests now pass on FreeBSD. How about OSX?

[tmonteil]

Note that the current cmake 3.8.0 does not build on OSX, see ​https://trac.sagemath.org/ticket/22817#comment:9

[slabbe]

On OSX Yosemite 10.10.2, I can't compile cmake 3.8.1 (same error as cmake 3.8.0 I reported in #22817):

$ MAKE='make -j2' sage -i cmake

...

[cmake-3.8.1] [ 31%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_set_format_ar.c.o
[cmake-3.8.1] [ 31%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_set_format_by_name.c.o
[cmake-3.8.1] [ 31%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_set_format_cpio.c.o
[cmake-3.8.1] [ 31%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_set_format_cpio_newc.c.o
[cmake-3.8.1] [ 32%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_write_set_format_filter_by_ext.c.o
[cmake-3.8.1] In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/dispatch/dispatch.h:50:0,
[cmake-3.8.1]                  from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFStream.h:15,
[cmake-3.8.1]                  from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFPropertyList.h:13,
[cmake-3.8.1]                  from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:55,
[cmake-3.8.1]                  from CPack/OSXScriptLauncher.cxx:11:
[cmake-3.8.1] ../../../../../../../include/dispatch/object.h:321:1: error: 'DISPATCH_UNAVAILABLE' does not name a type
[cmake-3.8.1]  DISPATCH_UNAVAILABLE
[cmake-3.8.1]  ^
[cmake-3.8.1] In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/dispatch/dispatch.h:50:0,
[cmake-3.8.1]                  from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFStream.h:15,
[cmake-3.8.1]                  from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFPropertyList.h:13,
[cmake-3.8.1]                  from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:55,
[cmake-3.8.1]                  from CPack/OSXScriptLauncher.cxx:11:
[cmake-3.8.1] ../../../../../../../include/dispatch/object.h:358:1: error: 'DISPATCH_UNAVAILABLE' does not name a type
[cmake-3.8.1]  DISPATCH_UNAVAILABLE
[cmake-3.8.1]  ^
[cmake-3.8.1] In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/dispatch/dispatch.h:50:0,
[cmake-3.8.1]                  from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFStream.h:15,
[cmake-3.8.1]                  from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFPropertyList.h:13,
[cmake-3.8.1]                  from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:55,
[cmake-3.8.1]                  from CPack/OSXScriptLauncher.cxx:11:
[cmake-3.8.1] ../../../../../../../include/dispatch/object.h:387:1: error: 'DISPATCH_UNAVAILABLE' does not name a type
[cmake-3.8.1]  DISPATCH_UNAVAILABLE
[cmake-3.8.1]  ^
[cmake-3.8.1] In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/dispatch/dispatch.h:50:0,
[cmake-3.8.1]                  from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFStream.h:15,
[cmake-3.8.1]                  from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFPropertyList.h:13,
[cmake-3.8.1]                  from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:55,
[cmake-3.8.1]                  from CPack/OSXScriptLauncher.cxx:11:
[cmake-3.8.1] ../../../../../../../include/dispatch/object.h:418:1: error: 'DISPATCH_UNAVAILABLE' does not name a type
[cmake-3.8.1]  DISPATCH_UNAVAILABLE
[cmake-3.8.1]  ^
[cmake-3.8.1] make[4]: *** [Source/CMakeFiles/OSXScriptLauncher.dir/CPack/OSXScriptLauncher.cxx.o] Error 1
[cmake-3.8.1] make[3]: *** [Source/CMakeFiles/OSXScriptLauncher.dir/all] Error 2
[cmake-3.8.1] make[3]: *** Waiting for unfinished jobs....

...

[cmake-3.8.1] make[2]: *** [all] Error 2
[cmake-3.8.1] Error installing CMake.
[cmake-3.8.1] 
[cmake-3.8.1] real	3m12.199s
[cmake-3.8.1] user	1m45.730s
[cmake-3.8.1] sys	1m13.808s
[cmake-3.8.1] ************************************************************************
[cmake-3.8.1] Error installing package cmake-3.8.1
[cmake-3.8.1] ************************************************************************

...

I will upload the log file in a moment.

I am using:

$ xcodebuild -version
Xcode 6.3
Build version 6D570

[slabbe]

On OSX 10.10.2 Yosemite with XCode 6.3

[slabbe]

A similar error was reported in ​https://trac.sagemath.org/ticket/18078#comment:10

and the following patch (deleted in #22814 : update cmake to 3.8.0) was used to fix the issue:

git show c73f9e2a65d7bf25506db176b0832c2d2cb73edd

[slabbe]

I tried to reuse the same osx10.10.patch, but it does not apply on cmake-3.8.1 anymore.

[tmonteil]

Replying to slabbe:

I tried to reuse the same osx10.10.patch, but it does not apply on cmake-3.8.1 anymore.

I rewrote the patch so that it applies on cmake-3.8.1, and add it to the branch, does this fix the issue ?

---

New commits:

​15d1b35

#21668 : rewrite osx10.10.patch for cmake 3.8.1.

[tmonteil]

FWIW, the current branch compiles and self-tests pass on my x86_64 laptop.

[slabbe]

Sorry, my internet connection is not working or very slow...

I still get an error:

[cmake-3.8.1] [ 88%] Building CXX object Source/CMakeFiles/CTestLib.dir/CTest/cmParseMumpsCoverage.cxx.o
[cmake-3.8.1] In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/dispatch/dispatch.h:50:0,
[cmake-3.8.1]                  from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFStream.h:15,
[cmake-3.8.1]                  from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFPropertyList.h:13,
[cmake-3.8.1]                  from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:55,
[cmake-3.8.1]                  from CPack/cmCPackDragNDropGenerator.cxx:16:
[cmake-3.8.1] ../../../../../../../include/dispatch/object.h:321:1: error: 'DISPATCH_UNAVAILABLE' does not name a type
[cmake-3.8.1]  DISPATCH_UNAVAILABLE
[cmake-3.8.1]  ^
[cmake-3.8.1] In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/dispatch/dispatch.h:50:0,
[cmake-3.8.1]                  from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFStream.h:15,
[cmake-3.8.1]                  from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFPropertyList.h:13,
[cmake-3.8.1]                  from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:55,
[cmake-3.8.1]                  from CPack/cmCPackDragNDropGenerator.cxx:16:
[cmake-3.8.1] ../../../../../../../include/dispatch/object.h:358:1: error: 'DISPATCH_UNAVAILABLE' does not name a type
[cmake-3.8.1]  DISPATCH_UNAVAILABLE
[cmake-3.8.1]  ^
[cmake-3.8.1] In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/dispatch/dispatch.h:50:0,
[cmake-3.8.1]                  from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFStream.h:15,
[cmake-3.8.1]                  from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFPropertyList.h:13,
[cmake-3.8.1]                  from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:55,
[cmake-3.8.1]                  from CPack/cmCPackDragNDropGenerator.cxx:16:
[cmake-3.8.1] ../../../../../../../include/dispatch/object.h:387:1: error: 'DISPATCH_UNAVAILABLE' does not name a type
[cmake-3.8.1]  DISPATCH_UNAVAILABLE
[cmake-3.8.1]  ^
[cmake-3.8.1] In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/dispatch/dispatch.h:50:0,
[cmake-3.8.1]                  from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFStream.h:15,
[cmake-3.8.1]                  from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFPropertyList.h:13,
[cmake-3.8.1]                  from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:55,
[cmake-3.8.1]                  from CPack/cmCPackDragNDropGenerator.cxx:16:
[cmake-3.8.1] ../../../../../../../include/dispatch/object.h:418:1: error: 'DISPATCH_UNAVAILABLE' does not name a type
[cmake-3.8.1]  DISPATCH_UNAVAILABLE
[cmake-3.8.1]  ^
[cmake-3.8.1] CPack/cmCPackDragNDropGenerator.cxx: In member function 'virtual int cmCPackDragNDropGenerator::PackageFiles()':
[cmake-3.8.1] CPack/cmCPackDragNDropGenerator.cxx:181:3: error: 'sort' is not a member of 'std'
[cmake-3.8.1]    std::sort(package_files.begin(), package_files.end());
[cmake-3.8.1]    ^
[cmake-3.8.1] CPack/cmCPackDragNDropGenerator.cxx:182:23: error: 'unique' is not a member of 'std'
[cmake-3.8.1]    package_files.erase(std::unique(package_files.begin(), package_files.end()),
[cmake-3.8.1]                        ^
[cmake-3.8.1] make[4]: *** [Source/CMakeFiles/CPackLib.dir/CPack/cmCPackDragNDropGenerator.cxx.o] Error 1
[cmake-3.8.1] make[3]: *** [Source/CMakeFiles/CPackLib.dir/all] Error 2
[cmake-3.8.1] make[3]: *** Waiting for unfinished jobs....

[slabbe]

Maybe the patch should contain one more fix?

$ cd local/var/tmp/sage/build/cmake-3.8.1
$ grep CoreFoundation src/Source/*.cxx
src/Source/cmFindProgramCommand.cxx:#include <CoreFoundation/CFBundle.h>
src/Source/cmXCodeObject.cxx:#include <CoreFoundation/CFUUID.h>
$ grep CoreFoundation src/Source/CPack/*.cxx
src/Source/CPack/OSXScriptLauncher.cxx:#include <CoreFoundation/CFBundle.h>
src/Source/CPack/cmCPackDragNDropGenerator.cxx:#include <CoreFoundation/CoreFoundation.h>

[tmonteil]

Adding Isuru Fernando who wrote the first OSX patch in CC.

[isuruf]

Yes, looks like Source/CPack/cmCPackDragNDropGenerator.cxx needs to replace <CoreFoundation/CoreFoundation.h> with <CoreFoundation/CFString.h>. I don't have access to OSX to check this though.

Btw, #12426 makes this patch unnecessary, but I guess it will take time before that ticket is merged.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​3a48f27

#21668 : update osx10.10.patch w.r.t. comment 39.

[tmonteil]

Replying to isuruf:

Yes, looks like Source/CPack/cmCPackDragNDropGenerator.cxx needs to replace <CoreFoundation/CoreFoundation.h> with <CoreFoundation/CFString.h>. I don't have access to OSX to check this though.

Thanks for the hint, i updated the patch.

Note that the following files still refer to <CoreFoundation/CoreFoundation.h>

Utilities/cmlibuv/src/unix/darwin-proctitle.c
Utilities/cmcurl/lib/vtls/darwinssl.c
Tests/BundleTest/BundleTest.cxx
Tests/BundleTest/BundleLib.cxx

Should we update them too (and by what should CoreFoundation.h be replaced there ?) ?

[jhpalmieri]

Replying to isuruf:

Yes, looks like Source/CPack/cmCPackDragNDropGenerator.cxx needs to replace <CoreFoundation/CoreFoundation.h> with <CoreFoundation/CFString.h>. I don't have access to OSX to check this though.

Btw, #12426 makes this patch unnecessary, but I guess it will take time before that ticket is merged.

Would it make sense then to get rid of the patch and to build cmake with clang, even without #12426? We already do this with several other packages (Python, R, and I think others). So we could add to the spkg-install script:

if [ "$UNAME" = Darwin ]; then
    CC=clang
    CXX=clang++
fi

That works for me with the version of cmake on this ticket.

[isuruf]

Would it make sense then to get rid of the patch and to build cmake with clang, even without #12426?

If you are going in that path, you'd have to use the bundled dependencies instead of the ones in the Sage tree. Sage's packages like curl, xz are built with gcc and mixing them with clang is never a good idea.

Should we update them too (and by what should CoreFoundation.h be replaced there ?) ?

Some of those headers uses lots of functions starting with CF. Somebody with access to OSX 10.10 would have to figure out what headers are actually needed.

[slabbe]

... just got my internet connection back.

I managed to

[cmake-3.8.1] Successfully installed cmake-3.8.1

on OSX 10.10 with this patch:

diff -dru src/Source/CPack/cmCPackDragNDropGenerator.cxx new/Source/CPack/cmCPackDragNDropGenerator.cxx
--- src/Source/CPack/cmCPackDragNDropGenerator.cxx  2017-05-02 14:59:43.000000000 +0200
+++ new/Source/CPack/cmCPackDragNDropGenerator.cxx  2017-05-18 20:00:39.000000000 +0200
@@ -12,8 +12,9 @@
 #include <iomanip>
 #include <map>
 #include <stdlib.h>
+#include <algorithm>
 
-#include <CoreFoundation/CoreFoundation.h>
+#include <CoreFoundation/CFBundle.h>
 
 #ifdef HAVE_CoreServices
 // For the old LocaleStringToLangAndRegionCodes() function, to convert

The include <algorithm> was to avoid error: 'sort' is not a member of 'std' according to stackoverflow. I will now test CFString.h approach.

[slabbe]

With the recently updated branch, no more error: 'DISPATCH_UNAVAILABLE' does not name a type but I still get:

$ MAKE='make -j2' sage -f cmake

...

[cmake-3.8.1] [ 96%] Linking CXX executable ../bin/ccmake
[cmake-3.8.1] CPack/cmCPackDragNDropGenerator.cxx: In member function 'virtual int cmCPackDragNDropGenerator::PackageFiles()':
[cmake-3.8.1] CPack/cmCPackDragNDropGenerator.cxx:181:3: error: 'sort' is not a member of 'std'
[cmake-3.8.1]    std::sort(package_files.begin(), package_files.end());
[cmake-3.8.1]    ^
[cmake-3.8.1] CPack/cmCPackDragNDropGenerator.cxx:182:23: error: 'unique' is not a member of 'std'
[cmake-3.8.1]    package_files.erase(std::unique(package_files.begin(), package_files.end()),
[cmake-3.8.1]                        ^
[cmake-3.8.1] make[4]: *** [Source/CMakeFiles/CPackLib.dir/CPack/cmCPackDragNDropGenerator.cxx.o] Error 1
[cmake-3.8.1] make[3]: *** [Source/CMakeFiles/CPackLib.dir/all] Error 2
[cmake-3.8.1] make[3]: *** Waiting for unfinished jobs....
[cmake-3.8.1] [ 96%] Built target ccmake
[cmake-3.8.1] make[2]: *** [all] Error 2
[cmake-3.8.1] Error installing CMake.
[cmake-3.8.1] 
[cmake-3.8.1] real	2m53.137s
[cmake-3.8.1] user	1m19.425s
[cmake-3.8.1] sys	1m3.994s
[cmake-3.8.1] ************************************************************************
[cmake-3.8.1] Error installing package cmake-3.8.1
[cmake-3.8.1] ************************************************************************

Therefore, the CFBundle.h or CFString.h both work. But #include <algorithm> seems to be necessary.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​f5ce853

#21668 : update osx10.10.patch w.r.t. comment 45.

[tmonteil]

Replying to slabbe:

Therefore, the CFBundle.h or CFString.h both work. But #include <algorithm> seems to be necessary.

Patch updated.

[tmonteil]

Could you also test with sage -f -c cmake to see if self-tests pass ?

[slabbe]

I confirm that it now works on OSX 10.10:

$ MAKE='make -j2' sage -f cmake
...
[cmake-3.8.1] Successfully installed cmake-3.8.1
[cmake-3.8.1] Deleting temporary build directory
[cmake-3.8.1] /Users/slabbe/Applications/sage-git/local/var/tmp/sage/build/cmake-3.8.1
[cmake-3.8.1] Finished installing cmake-3.8.1.spkg

(why .spkg?)

I will now do the -f -c and report back.

[slabbe]

Still running the tests...

[cmake-3.8.1] 126/448 Test #126: CPackComponentsForAll-DragNDrop-OnePackPerGroup ......   Passed   50.00 sec

I just saw this typo in the branch:

acknoledged

Also, the last three commits refer erroneously to 21668. I think the commit messages should be edited to 22999 to avoid possible confusion.

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​8de5fc7	Trac #22999 : rewrite osx10.10.patch for cmake 3.8.1.
​5ca4ce5	Trac #22999 : update osx10.10.patch w.r.t. comment 39.
​ef2291b	Trac #22999 : update osx10.10.patch w.r.t. comment 45.

[tmonteil]

Replying to slabbe:

Also, the last three commits refer erroneously to 21668. I think the commit messages should be edited to 22999 to avoid possible confusion.

For some reason i ignore, my branch was called t/22999/21668, then i copy/pasted the wrong number. Should be fixed now, sorry for the noise.

[fbissey]

Replying to isuruf:

Would it make sense then to get rid of the patch and to build cmake with clang, even without #12426?

If you are going in that path, you'd have to use the bundled dependencies instead of the ones in the Sage tree. Sage's packages like curl, xz are built with gcc and mixing them with clang is never a good idea.

Not necessarily. It depends if they are pure C library or if they have C++ in them. If is OK to mix compiler for pure C code (standard compliant code, most of the time) mainly thanks to the fact that the C language is well established and that in both gcc and clang case you will use the OS' libc. As a matter of fact we already compile several packages on OS X with clang instead of gcc to avoid the system header problem. The most troublesome being python itself (and then you compile all the python modules with gcc and yet it works!). And you should also note that curl is actually a clang compile on OS X too.

So I'd only build libraries that cmake links too containing c++. At the present time I believe it is none, so it is quite safe.

[slabbe]

Ok, so I get:

[cmake-3.8.1] The following tests FAILED:
[cmake-3.8.1] 	168 - XCTest (Failed)
[cmake-3.8.1] 	177 - ObjC++ (Failed)
[cmake-3.8.1] 	386 - RunCMake.FindGTK2 (Failed)
[cmake-3.8.1] Errors while running CTest

The first two have such error line:

gcc: error: /Users/slabbe/Applications/sage-git/local/var/tmp/sage/build/cmake-3.8.1/src/Tests/XCTest/CocoaExample/main.m: Objective-C compiler not installed on this system

I am not able to understand test 386, so I paste all of it:

test 386
        Start 386: RunCMake.FindGTK2

386: Test command: /Users/slabbe/Applications/sage-git/local/var/tmp/sage/build/cmake-3.8.1/src/bin/cmake "-DCMAKE_MODULE_PATH=/Users/slabbe/Applications/sage-git/local/var/tmp/sage/build/cmake-3.8.1/src/Tests/RunCMake" "-DRunCMake_GENERATOR=Unix Makefiles" "-DRunCMake_GENERATOR_PLATFORM=" "-DRunCMake_GENERATOR_TOOLSET=" "-DRunCMake_MAKE_PROGRAM=/usr/bin/make" "-DRunCMake_SOURCE_DIR=/Users/slabbe/Applications/sage-git/local/var/tmp/sage/build/cmake-3.8.1/src/Tests/RunCMake/FindGTK2" "-DRunCMake_BINARY_DIR=/Users/slabbe/Applications/sage-git/local/var/tmp/sage/build/cmake-3.8.1/src/Tests/RunCMake/FindGTK2" "-P" "/Users/slabbe/Applications/sage-git/local/var/tmp/sage/build/cmake-3.8.1/src/Tests/RunCMake/FindGTK2/RunCMakeTest.cmake"
386: Test timeout computed to be: 1500
386: CMake Error at RunCMake.cmake:132 (message):
386:   FindGTK2RunTwice - FAILED:
386: 
386:   Result is [1], not [0].
386: 
386:   stderr does not match that expected.
386: 
386:   Actual stdout:
386: 
386:    actual-out> Not searching for unused variables given on the command line.
386:    actual-out> -- The C compiler identification is GNU 4.9.3
386:    actual-out> -- Checking whether C compiler has -isysroot
386:    actual-out> -- Checking whether C compiler has -isysroot - yes
386:    actual-out> -- Checking whether C compiler supports OSX deployment target flag
386:    actual-out> -- Checking whether C compiler supports OSX deployment target flag - yes
386:    actual-out> -- Check for working C compiler: /Users/slabbe/Applications/sage-git/local/libexec/ccache/gcc
386:    actual-out> -- Check for working C compiler: /Users/slabbe/Applications/sage-git/local/libexec/ccache/gcc -- works
386:    actual-out> -- Detecting C compiler ABI info
386:    actual-out> -- Detecting C compiler ABI info - done
386:    actual-out> -- Detecting C compile features
386:    actual-out> -- Detecting C compile features - done
386:    actual-out> -- Found GTK2_GTK: /opt/local/lib/libgtk-x11-2.0.dylib  
386:    actual-out> -- Configuring incomplete, errors occurred!
386:    actual-out> See also "/Users/slabbe/Applications/sage-git/local/var/tmp/sage/build/cmake-3.8.1/src/Tests/RunCMake/FindGTK2/FindGTK2RunTwice-build/CMakeFiles/CMakeOutput.log".
386: 
386:   Expected stderr to match:
386: 
386:    expect-err> ^$
386: 
386:   Actual stderr:
386: 
386:    actual-err> CMake Error at FindGTK2RunTwice.cmake:16 (message):
386:    actual-err>   GTK2_LIBRARIES is different:
386:    actual-err> 
386:    actual-err>   before:
386:    actual-err>   /opt/local/lib/libglib-2.0.dylib;/opt/local/lib/libgobject-2.0.dylib;/opt/local/lib/libatk-1.0.dylib;/opt/local/lib/libgio-2.0.dylib;/opt/local/lib/libgthread-2.0.dylib;/opt/local/lib/libgmodule-2.0.dylib;/opt/local/lib/libgdk_pixbuf-2.0.dylib;/opt/local/lib/libcairo.dylib;/opt/local/lib/libpango-1.0.dylib;/opt/local/lib/libpangocairo-1.0.dylib;/opt/local/lib/libpangoft2-1.0.dylib;/opt/local/lib/libpangoxft-1.0.dylib;/opt/local/lib/libgdk-x11-2.0.dylib;/opt/local/lib/libgtk-x11-2.0.dylib
386:    actual-err> 
386:    actual-err> 
386:    actual-err>   after:
386:    actual-err>   /opt/local/lib/libglib-2.0.dylib;/opt/local/lib/libgobject-2.0.dylib;/opt/local/lib/libatk-1.0.dylib;/opt/local/lib/libgio-2.0.dylib;/opt/local/lib/libgthread-2.0.dylib;/opt/local/lib/libgmodule-2.0.dylib;/opt/local/lib/libgdk_pixbuf-2.0.dylib;/opt/local/lib/libcairo.dylib;/opt/local/lib/libpango-1.0.dylib;/opt/local/lib/libpangocairo-1.0.dylib;/opt/local/lib/libpangoft2-1.0.dylib;/opt/local/lib/libpangoxft-1.0.dylib;/opt/local/lib/libgdk-x11-2.0.dylib;/opt/local/lib/libgdk-x11-2.0.dylib;/opt/local/lib/libgtk-x11-2.0.dylib;/opt/local/lib/libgtk-x11-2.0.dylib
386:    actual-err> Call Stack (most recent call first):
386:    actual-err>   CMakeLists.txt:3 (include)
386: 
386: Call Stack (most recent call first):
386:   FindGTK2/RunCMakeTest.cmake:3 (run_cmake)
386: 
386: 
386/448 Test #386: RunCMake.FindGTK2 ....................................***Failed    8.61 sec

[fbissey]

It looks like you have a local install of gtk2 on OS X and cmake has trouble figuring out your install. I am not sure how it looks for the libraries (I think .pc files) but your install has a library in triplicate compared to what is expected. I would presume that it is done to an error in configuration of your local gtk2 package.

The other 2 are a bit puzzling. Yes gcc/g++ was not built as an objective-C/objective-C++ compiler. But we set those to clang/clang++ in sage-env so there is a different problem. I wonder if cmake is trying to use CC/CXX as objective compilers rather than using the correct OBJC/OBJCXX.

In any case I think we should just compile cmake with clang/clang++. As I said before it shouldn't be a problem at this time. That wouldn't solve your gtk2 problem because I think your gtk2 install is at fault here.

[slabbe]

In case it helps, here are more context for the first two failing tests:

168: Run Build Command:"/usr/bin/make"
168: -- Configuring done
168: -- Generating done
168: -- Build files have been written to: /Users/slabbe/Applications/sage-git/local/var/tmp/sage/build/cmake-3.8.1/src/Tests/XCTest
168: Scanning dependencies of target CocoaExample
168: [ 11%] Building C object CMakeFiles/CocoaExample.dir/CocoaExample/main.m.o
168: gcc: error: /Users/slabbe/Applications/sage-git/local/var/tmp/sage/build/cmake-3.8.1/src/Tests/XCTest/CocoaExample/main.m: Objective-C compiler not installed on this system
168: make[4]: *** [CMakeFiles/CocoaExample.dir/CocoaExample/main.m.o] Error 1
168: make[3]: *** [CMakeFiles/CocoaExample.dir/all] Error 2
168: make[2]: *** [all] Error 2
168/448 Test #168: XCTest ...............................................***Failed   11.06 sec

177: Run Build Command:"/usr/bin/make"
177: Scanning dependencies of target ObjC++
177: [ 50%] Building CXX object CMakeFiles/ObjC++.dir/objc++.mm.o
177: g++: error: /Users/slabbe/Applications/sage-git/local/var/tmp/sage/build/cmake-3.8.1/src/Tests/ObjC++/objc++.mm: Objective-C++ compiler not installed on this system
177: make[4]: *** [CMakeFiles/ObjC++.dir/objc++.mm.o] Error 1
177: make[3]: *** [CMakeFiles/ObjC++.dir/all] Error 2
177: make[2]: *** [all] Error 2
177/448 Test #177: ObjC++ ...............................................***Failed    9.65 sec

[slabbe]

Replying to fbissey:

I think your gtk2 install is at fault here.

Ok, so what should I do to fix the installation of gtk2? Uninstall and reinstall? With sudo port ...? I never directly used/installed gtk before...

[fbissey]

Could be a cmake upstream mistake. It shouldn't be C/CXX objects if it has objective C/C++ bits in it. I may dig it a bit, but it looks like it expect CC and CXX to be "objective" capable without checking first.

I cannot say about gtk2. I have never installed it either. All I know from your logs is you have it under /opt. Let's see what is under /opt/local/lib/pkgconfig on your system.

[slabbe]

$ ls /opt/local/lib/pkgconfig/gtk*
/opt/local/lib/pkgconfig/gtk+-2.0.pc	
/opt/local/lib/pkgconfig/gtk+-unix-print-2.0.pc	
/opt/local/lib/pkgconfig/gtk+-x11-2.0.pc

and their content is:

$ cat /opt/local/lib/pkgconfig/gtk+-2.0.pc 
prefix=/opt/local
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
target=x11

gtk_binary_version=2.10.0
gtk_host=x86_64-apple-darwin14.5.0

Name: GTK+
Description: GTK+ Graphical UI Library (${target} target)
Version: 2.24.28
Requires: gdk-${target}-2.0 atk cairo gdk-pixbuf-2.0 gio-2.0 pangoft2
Libs: -L${libdir} -lgtk-${target}-2.0 
Cflags: -I${includedir}/gtk-2.0 

$ cat /opt/local/lib/pkgconfig/gtk+-unix-print-2.0.pc
prefix=/opt/local
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
target=x11

gtk_binary_version=2.10.0
gtk_host=x86_64-apple-darwin14.5.0

Name: GTK+
Description: GTK+ Unix print support
Version: 2.24.28
Requires: gtk+-${target}-2.0 atk cairo gdk-pixbuf-2.0 gio-2.0 pangoft2
Cflags: -I${includedir}/gtk-unix-print-2.0

$ diff /opt/local/lib/pkgconfig/gtk+-2.0.pc /opt/local/lib/pkgconfig/gtk+-x11-2.0.pc
$

[fbissey]

By the way how did it get there? What installed it?

[fbissey]

Do you have a pkg-config command that see that folder as part of it configuration path - I would image so but we never know. pkg-config --libs-only-l gtk+2.0 should tell us what is the normal output.

[slabbe]

I do not remember, but the files are dating:

$ ll /opt/local/lib/pkgconfig/gtk*
-rw-r--r--  1 root  admin  397 14 oct  2015 /opt/local/lib/pkgconfig/gtk+-2.0.pc
-rw-r--r--  1 root  admin  348 14 oct  2015 /opt/local/lib/pkgconfig/gtk+-unix-print-2.0.pc
-rw-r--r--  1 root  admin  397 14 oct  2015 /opt/local/lib/pkgconfig/gtk+-x11-2.0.pc

I do not have pkg-config command, but it is available in sage-sh :

$ pkg-config --libs-only-l gtk+2.0
-bash: pkg-config: command not found
$ sage -sh
(sage-sh) $ pkg-config --libs-only-l gtk+2.0
Package gtk+2.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `gtk+2.0.pc'
to the PKG_CONFIG_PATH environment variable
Package 'gtk+2.0', required by 'world', not found

[fbissey]

Not sure how cmake finds it then, I'll have to inspect. PKG_CONFIG_PATH= PKG_CONFIG_PATH pkg-config --libs-only-l gtk+2.0 would work but I don't think that cmake uses that if it is not found by default.

[slabbe]

There was a typo. It is gtk+-2.0 not gtk+2.0:

$ /opt/local/bin/pkg-config --libs-only-l gtk+-2.0
-lgtk-x11-2.0 -lgdk-x11-2.0 -lpangocairo-1.0 -lgio-2.0 -lXrender -lXinerama -lXi 
-lXrandr -lXcursor -lXcomposite -lXdamage -lXfixes -lX11 -lXext -latk-1.0 -lcairo 
-lgdk_pixbuf-2.0 -lgio-2.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 
-lintl -lfontconfig -lfreetype 

[slabbe]

Replying to jhpalmieri:

Would it make sense then to get rid of the patch and to build cmake with clang, even without #12426? We already do this with several other packages (Python, R, and I think others). So we could add to the spkg-install script:

if [ "$UNAME" = Darwin ]; then
    CC=clang
    CXX=clang++
fi

That works for me with the version of cmake on this ticket.

What is next for this ticket? Do we keep the osx patch, or should we test the other option mentionned in jhpalmieri for using clang?

[fbissey]

My vote is to go clang simpler, easier to maintain. Open to revision if there are C++ problems. In fact I'd say we should try with only CC=clang and leave CXX alone. The only problems are usually related to the C language because apple uses a clang extension to C, with no equivalent in gcc, in OS X's libc and headers. C++ should be safe.

[jhpalmieri]

I originally tried with just CC=clang but the build failed. It succeeded when I added CXX=clang++. But I may have made mistakes, so please try it both ways.

[fbissey]

Replying to jhpalmieri:

I originally tried with just CC=clang but the build failed. It succeeded when I added CXX=clang++. But I may have made mistakes, so please try it both ways.

You can get into such problems if at some point the C compiler is used to compile C++ code, which happens more often than it should. I will have a look when I have time, I have to inspect a gf2x patch first (should have done so yesterday). Setting CXX is not a big deal if

• you don't depend on libraries that are compiled with another C++ compiler (current situation)
• you only produce executable and no libraries to be consumed down the line (current situation with cmake)

[fbissey]

I forgot! I don't have gcc build of sage on my little laptop anymore. Much too stressing compared to the result of my work with clang at #12426.

[dimpase]

I think we should go with clang on OSX, full stop. What else is holding up this?

[dimpase]

I can provide accounts on a 32-bit system (arando buildbot) for anyone who wants to do a 32-bit Linux test.

[fbissey]

I shall try to compare my an Thierry's branch and put things in the proper order. I don't think I can solve Sebastien's failure with gtk2, but that's an uncommon configuration that will be rare.

[slabbe]

Deleting file build/pkgs/cmake/patches/osx10.10.patch and with this modif:

build/pkgs/cmake/spkg-install

@@ -1 +1 @@
 #!/usr/bin/env bash
 
+if [ "$UNAME" = Darwin ]; then
+    CC=clang
+    #CXX=clang++
+fi
+
 cd src
 
 ./bootstrap --prefix=$SAGE_LOCAL \

I get a similar error as before without the osx patch:

[cmake-3.8.1] ---------------------------------------------
[cmake-3.8.1] CMake 3.8.1, Copyright 2000-2017 Kitware, Inc. and Contributors
[cmake-3.8.1] C compiler on this system is: clang
[cmake-3.8.1] C++ compiler on this system is: g++
...
[cmake-3.8.1]                  from CPack/OSXScriptLauncher.cxx:11:
[cmake-3.8.1] ../../../../../../../include/dispatch/object.h:321:1: error: 'DISPATCH_UNAVAILABLE' does not name a type
[cmake-3.8.1]  DISPATCH_UNAVAILABLE
[cmake-3.8.1]  ^

Full log is at ​https://pastebin.com/L0CEd4hd

Setting both CC and CXX,

build/pkgs/cmake/spkg-install

@@ -1 +1 @@
 #!/usr/bin/env bash
 
+if [ "$UNAME" = Darwin ]; then
+    CC=clang
+    CXX=clang++
+fi
+
 cd src
 
 ./bootstrap --prefix=$SAGE_LOCAL \

I get again:

[cmake-3.8.1] ---------------------------------------------
[cmake-3.8.1] CMake 3.8.1, Copyright 2000-2017 Kitware, Inc. and Contributors
[cmake-3.8.1] C compiler on this system is: clang
[cmake-3.8.1] C++ compiler on this system is: clang++
...
[cmake-3.8.1] ../../../../../../../include/dispatch/object.h:418:1: error: unknown type name 'DISPATCH_UNAVAILABLE'
[cmake-3.8.1] DISPATCH_UNAVAILABLE
[cmake-3.8.1] ^
[cmake-3.8.1] ../../../../../../../include/dispatch/object.h:419:1: error: expected unqualified-id
[cmake-3.8.1] extern __attribute__((visibility("default"))) __attribute__((__nonnull__)) __attribute__((__warn_unused_result__)) __attribute__((__pure__))
[cmake-3.8.1] ^
[cmake-3.8.1] In file included from CPack/OSXScriptLauncher.cxx:11:
[cmake-3.8.1] In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:55:
[cmake-3.8.1] In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFPropertyList.h:13:
[cmake-3.8.1] In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFStream.h:15:
[cmake-3.8.1] In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/dispatch/dispatch.h:52:
[cmake-3.8.1] /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/dispatch/queue.h:111:16: error: typedef redefinition with different types ('void (^)()' vs 'void *')
[cmake-3.8.1] typedef void (^dispatch_block_t)(void);
[cmake-3.8.1]                ^
[cmake-3.8.1] ../../../../../../../include/dispatch/object.h:143:15: note: previous definition is here
[cmake-3.8.1] typedef void* dispatch_block_t;
[cmake-3.8.1]               ^
[cmake-3.8.1] 9 errors generated.
[cmake-3.8.1] make[4]: *** [Source/CMakeFiles/OSXScriptLauncher.dir/CPack/OSXScriptLauncher.cxx.o] Error 1

Full log is at ​https://pastebin.com/052tS36d

So unless I did something wrong in the spkg-install, the osx patch seems to be needed.

[jhpalmieri]

I only have access to OS X 10.12, not 10.10. For me, I just confirmed that only setting CC=clang is not good enough: I also need CXX=clang++. This is true with or without the patch.

[slabbe]

With CC=clang and CXX=clang++ with the osx patch on OSX 10.10, sage -f -c cmake gives:

...
[cmake-3.8.1] Successfully installed cmake-3.8.1
[cmake-3.8.1] Running the test suite for cmake-3.8.1...
...
[cmake-3.8.1] Total Test time (real) = 3537.39 sec
[cmake-3.8.1] 
[cmake-3.8.1] The following tests FAILED:
[cmake-3.8.1] 	167 - XCTest (Failed)
[cmake-3.8.1] 	176 - ObjC++ (Failed)
[cmake-3.8.1] 	385 - RunCMake.FindGTK2 (Failed)
[cmake-3.8.1] 	386 - RunCMake.Framework (Failed)
[cmake-3.8.1] Errors while running CTest

Failed test log available at ​https://pastebin.com/wRZMB3v2

[slabbe]

Sharing my CC=clang and CXX=clang++ for Darwin branch.

---

New commits:

​3c4d94e	Merge branch 'u/tmonteil/cmakeupd' of trac.sagemath.org:sage into 8.0.beta7
​0754341	22999: Using CC=clang and CXX=clang++ on Darwin

[fbissey]

Replying to slabbe:

With CC=clang and CXX=clang++ with the osx patch on OSX 10.10, sage -f -c cmake gives:

...
[cmake-3.8.1] Successfully installed cmake-3.8.1
[cmake-3.8.1] Running the test suite for cmake-3.8.1...
...
[cmake-3.8.1] Total Test time (real) = 3537.39 sec
[cmake-3.8.1] 
[cmake-3.8.1] The following tests FAILED:
[cmake-3.8.1] 	167 - XCTest (Failed)
[cmake-3.8.1] 	176 - ObjC++ (Failed)
[cmake-3.8.1] 	385 - RunCMake.FindGTK2 (Failed)
[cmake-3.8.1] 	386 - RunCMake.Framework (Failed)
[cmake-3.8.1] Errors while running CTest

Failed test log available at ​https://pastebin.com/wRZMB3v2

The compilers also also need to be set in spkg-check. That should take of everything except the gtk2 test which is in its own basket.

It looks like the patch is needed for older version of OS X. I would have expected upstream cmake to do something about it. May be they abandoned the bug since it is fixed in newer version of OS X.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​0a16efc

22999: Using CC=clang and CXX=clang++ on Darwin for spkg-check too

[slabbe]

Will rerun sage -f -c cmake on my osx 10.10 overnight and will report back tomorrow.

[isuruf]

I think the redefinition failure is due to, ​https://github.com/sagemath/sage/blob/8.0.beta8/build/pkgs/gcc/spkg-install#L67-L68

[slabbe]

The compilers also also need to be set in spkg-check. That should take of everything except the gtk2 test which is in its own basket.

Indeed, with CC=clang and CXX=clang++ inside of spkg-check with the osx patch on OSX 10.10, sage -f -c cmake gives:

...
[cmake-3.8.1] 99% tests passed, 1 tests failed out of 448
[cmake-3.8.1] 
[cmake-3.8.1] Total Test time (real) = 2768.32 sec
[cmake-3.8.1] 
[cmake-3.8.1] The following tests FAILED:
[cmake-3.8.1] 	385 - RunCMake.FindGTK2 (Failed)
[cmake-3.8.1] Errors while running CTest
...

[slabbe]

Indeed, this sed command is done on my system:

$ diff local/include/dispatch/object.h /usr/include/dispatch/object.h 
143c143
< typedef void* dispatch_block_t;
---
> typedef void (^dispatch_block_t)(void);

The two commits that introduced this fix in #17169 are:

commit f62f6c37abbc7dbbfc68a9e8faa7d2e81eb48ca9
Author: Volker Braun
Date:   Sat Oct 18 20:24:02 2014 +0100

    Evil workaround for broken OSX system header

commit 71b40c25588244fd022b9cc697fa62626bdab3b2
Author: Volker Braun
Date:   Wed Oct 29 10:32:28 2014 +0000

    Check if dispatch/object.h is present

[slabbe]

With osx 10.10 + 8.0.beta7 + #22999 + the following changes:

$ mv local/include/dispatch/object.h local/include/dispatch/object.h.no
$ git rm build/pkgs/cmake/patches/osx10.10.patch 

I get

$ sage -f cmake
...
[cmake-3.8.1] Successfully installed cmake-3.8.1

What was the Evil workaround for?

[fbissey]

If memory serves me right, gcc would fail to compile without it. The header probably has some of that enum extension clang uses. Since I don't use gcc anymore on OS X I didn't suffer from that problem.

[isuruf]

Problem with that patching with sed was that it only changed /usr/include/dispatch/object.h. I think it makes sense to copy the entire contents of /usr/include/dispatch/* and patch them. This might make building with gcc also possible without the osx10.10 patch.

[slabbe]

What about

• keeping the sed of the gcc spkg-install patching the local/include/dispatch/object.h
• keeping the osx 10.10 patch for cmake-3.8.1
• keeping C=clang and CXX=clang++ for cmake spkg-install and spkg-check
• (maybe) change type of cmake from experimental to optional?
• giving this ticket a positive review.

Then, leave sed improvements to spkg-install of gcc to another ticket?

[fbissey]

Replying to slabbe:

What about

• keeping the sed of the gcc spkg-install patching the local/include/dispatch/object.h
• keeping the osx 10.10 patch for cmake-3.8.1
• keeping C=clang and CXX=clang++ for cmake spkg-install and spkg-check
• (maybe) change type of cmake from experimental to optional?
• giving this ticket a positive review.

Then, leave sed improvements to spkg-install of gcc to another ticket?

I was actually writing something similar. +1 to all the above.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​40dc987

22999: cmake pkg type from optional to experimental

[fbissey]

That commit comment is backwards :)

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​719acc3

22999: cmake pkg type from optional to experimental

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​a4ad8d4

22999: cmake pkg type from experimental to optional

[slabbe]

...sorry for the noise

To me this ticket is positive review. I let somebody else change the status because I did the last commit changing type from *experimental* to *optional*.

[fbissey]

I am happy with the content of the ticket. Positive review.

[tmonteil]

On my 32bit VM, i have 5 failing doctests:

The following tests FAILED:
	 77 - BundleUtilities (Failed)
	132 - CPackComponentsDEB-components-source (Failed)
	133 - CPackComponentsDEB-components-shlibdeps1 (Failed)
	135 - CPackComponentsDEB-components-depend2 (Failed)
	401 - RunCMake.CPack_DEB (Failed)
Errors while running CTest

The full log is too big to be uploaded, but you can download it at ​https://sagedebianlive.metelu.net/pastebin/cmake-3.8.1.log

If you see how to fix this, this would be awesome, otherwise i am fine if the ticket gets merged anyway.

[tmonteil]

Note that i also get those syslogs (from dmesg):

[92750.312181] cmsysTestProces[26596]: segfault at 4 ip 08049a94 sp bfc5b940 error 6 in cmsysTestProcess[8048000+a000]
[92750.315028] cmsysTestProces[26599]: segfault at 4 ip 08049a94 sp bfeea5b0 error 6 in cmsysTestProcess[8048000+a000]
[93156.430420] Crash[17110]: segfault at 0 ip 0804861b sp bf9be638 error 6 in Crash[8048000+1000]

[fbissey]

Dependency. According to all the tests output I inspected the program "file" is not available and that throw off the tests. Can you check if "file" is present on the VM and if not install it and try again?

[tmonteil]

Replying to fbissey:

Dependency. According to all the tests output I inspected the program "file" is not available and that throw off the tests. Can you check if "file" is present on the VM and if not install it and try again?

Thanks for the hint, this fixed most tests, but the following is still there:

[cmake-3.8.1] The following tests FAILED:
[cmake-3.8.1]    77 - BundleUtilities (Failed)
[cmake-3.8.1] Errors while running CTest

The new log can be found at ​https://sagedebianlive.metelu.net/pastebin/cmake-3.8.1.log.2

[fbissey]

I need a bit more time to dig that one. The log doesn't quite give me enough details on the failure. I suspect something but then I don't know why it happens. I need to inspect the source of the test.

[fbissey]

Ah, not an explanation but I suddenly had the memory that the gentoo ebuild skips that test:

	# Excluded tests:
	#    BootstrapTest: we actualy bootstrap it every time so why test it.
	#    BundleUtilities: bundle creation broken
	#    CTest.updatecvs: which fails to commit as root
	#    Fortran: requires fortran
	#    Qt4Deploy, which tries to break sandbox and ignores prefix
	#    TestUpload, which requires network access
	"${BUILD_DIR}"/bin/ctest ${ctestargs} \
		-E "(BootstrapTest|BundleUtilities|CTest.UpdateCVS|Fortran|Qt4Deploy|TestUpload)" \
		|| die "Tests failed"

and that's exactly what I think happened to you, the bundle was broken. It clearly says that it doesn't include the binaries at the beginning, why??? I just wish there was an upstream ticket number attached to this. I will add a line to skip that test when I can.

[fbissey]

OK "fix" is in.

---

New commits:

​a307700

skip over BundleUtilities test has it is broken on some platforms

[fbissey]

Ah, may be the issue ​https://cmake.org/Bug/view.php?id=13364 , can you tell us a bit more about your 32bit VM Thierry?

[tmonteil]

Replying to fbissey:

Ah, may be the issue ​https://cmake.org/Bug/view.php?id=13364 , can you tell us a bit more about your 32bit VM Thierry?

It is a minimalist qemu image where i installed (with debootstrap) a Debian jessie, i attach the creation script.

It is run with the command:

sudo qemu-system-i386 -cpu pentium3 -enable-kvm /tempo/monteil/qemu_images/qemu_debian_jessie_32.qcow2 -m 7G -hdb /tempo/monteil/common_disk -display none -net nic,model=virtio -net user -redir tcp:10022::22

[tmonteil]

[cmake-3.8.1] 100% tests passed, 0 tests failed out of 442

Thanks !

[slabbe]

What about

• keeping the sed of the gcc spkg-install patching the local/include/dispatch/object.h

On osx 10.10, with 8.0.beta9, I get problem building python2-2.7.13.p1 with errors in the log related to the fact that I moved local/include/dispatch/object.h to local/include/dispatch/object.h.no. Therefore, it seems that "the sed of the gcc spkg-install patching the local/include/dispatch/object.h" is necessary.

[python2-2.7.13.p1] Python build finished, but the necessary bits to build these modules were not found:
[python2-2.7.13.p1] bsddb185           dl                 gdbm           
[python2-2.7.13.p1] imageop            linuxaudiodev      ossaudiodev    
[python2-2.7.13.p1] spwd               sunaudiodev                       
[python2-2.7.13.p1] To find the necessary bits, look in setup.py in detect_modules() for the module's name.
[python2-2.7.13.p1]
[python2-2.7.13.p1]
[python2-2.7.13.p1] Failed to build these modules:
[python2-2.7.13.p1] _scproxy                                             
[python2-2.7.13.p1]
[python2-2.7.13.p1] running build_scripts
[python2-2.7.13.p1] creating build/scripts-2.7
[python2-2.7.13.p1] copying and adjusting /Users/slabbe/Applications/sage-git/local/var/tmp/sage/build/python2-2.7.13.p1/src/Tools/scripts/pydoc -> build/scripts-2.7
[python2-2.7.13.p1] copying and adjusting /Users/slabbe/Applications/sage-git/local/var/tmp/sage/build/python2-2.7.13.p1/src/Tools/scripts/idle -> build/scripts-2.7
[python2-2.7.13.p1] copying and adjusting /Users/slabbe/Applications/sage-git/local/var/tmp/sage/build/python2-2.7.13.p1/src/Tools/scripts/2to3 -> build/scripts-2.7
[python2-2.7.13.p1] copying and adjusting /Users/slabbe/Applications/sage-git/local/var/tmp/sage/build/python2-2.7.13.p1/src/Lib/smtpd.py -> build/scripts-2.7
[python2-2.7.13.p1] changing mode of build/scripts-2.7/pydoc from 644 to 755
[python2-2.7.13.p1] changing mode of build/scripts-2.7/idle from 644 to 755
[python2-2.7.13.p1] changing mode of build/scripts-2.7/2to3 from 644 to 755
[python2-2.7.13.p1] changing mode of build/scripts-2.7/smtpd.py from 644 to 755
[python2-2.7.13.p1] /usr/bin/install -c -m 644 ./Tools/gdb/libpython.py python.exe-gdb.py
[python2-2.7.13.p1] Error: the _scproxy module failed to build.
[python2-2.7.13.p1]
[python2-2.7.13.p1] real    1m2.132s
[python2-2.7.13.p1] user    0m25.040s
[python2-2.7.13.p1] sys    0m28.191s
[python2-2.7.13.p1] ************************************************************************
[python2-2.7.13.p1] Error installing package python2-2.7.13.p1
[python2-2.7.13.p1] ************************************************************************
[python2-2.7.13.p1] Please email sage-devel (http://groups.google.com/group/sage-devel)

[fbissey]

Aren't you building python with clang?

[slabbe]

Replying to fbissey:

Aren't you building python with clang?

I think no.

If I do sage -f python2, I get:

...
[python2-2.7.13.p1] ****************************************************
[python2-2.7.13.p1] C compiler: gcc
[python2-2.7.13.p1] C compiler version:
[python2-2.7.13.p1] Using built-in specs.
[python2-2.7.13.p1] COLLECT_GCC=/Users/slabbe/Applications/sage-git/local/bin/gcc
[python2-2.7.13.p1] COLLECT_LTO_WRAPPER=/Users/slabbe/Applications/sage-git/local/libexec/gcc/x86_64-apple-darwin14.1.0/4.9.3/lto-wrapper
[python2-2.7.13.p1] Target: x86_64-apple-darwin14.1.0
[python2-2.7.13.p1] Configured with: ../src/configure --prefix=/Users/slabbe/Applications/sage-git/local --with-local-prefix=/Users/slabbe/Applications/sage-git/local --with-gmp=/Users/slabbe/Applications/sage-git/local --with-mpfr=/Users/slabbe/Applications/sage-git/local --with-mpc=/Users/slabbe/Applications/sage-git/local --with-system-zlib --disable-multilib --disable-nls --enable-languages=c,c++,fortran --disable-libitm --with-build-config=bootstrap-debug --without-isl --without-cloog  
[python2-2.7.13.p1] Thread model: posix
[python2-2.7.13.p1] gcc version 4.9.3 (GCC) 
[python2-2.7.13.p1] ****************************************************
...

[fbissey]

You would have to look later in the log for building python. This is a standard header spouted by sage-skpg and it only tells you the compiler that sage has been configured to use. If you change CC in spkg-install this is done after that banner is printed.

[slabbe]

My python2-2.7.13.p1.log file as more than 30000 lines for the last call to sage -f python2 which was succesfull with

$ ls local/include/dispatch/
object.h

and

$ grep gcc logs/pkgs/python2-2.7.13.p1.log | wc
     324    6389  173447
$ grep clang logs/pkgs/python2-2.7.13.p1.log | wc
       6      34     457

with the 6 occurences of clang being in between to call to gcc:

...
gcc -fno-strict-aliasing -I/Users/slabbe/Applications/sage-git/local/var/tmp/sage/build/python2-2.7.13.p1/include -DNDEBUG -g -fwrapv -O3 -Wall -Wno-unused -I_ctypes/darwin -I/Users/slabbe/Applications/sage-git/local/var/tmp/sage/build/python2-2.7.13.p1/src/Modules/_ctypes/libffi_osx/include -I/Users/slabbe/Applications/sage-git/local/var/tmp/sage/build/python2-2.7.13.p1/src/Modules/_ctypes/libffi_osx/powerpc -I/Users/slabbe/Applications/sage-git/local/include -I. -IInclude -I./Include -I/usr/local/include -I/Users/slabbe/Applications/sage-git/local/var/tmp/sage/build/python2-2.7.13.p1/src/Include -I/Users/slabbe/Applications/sage-git/local/var/tmp/sage/build/python2-2.7.13.p1/src -c /Users/slabbe/Applications/sage-git/local/var/tmp/sage/build/python2-2.7.13.p1/src/Modules/_ctypes/libffi_osx/x86/x86-ffi64.c -o build/temp.macosx-10.9-x86_64-2.7/Users/slabbe/Applications/sage-git/local/var/tmp/sage/build/python2-2.7.13.p1/src/Modules/_ctypes/libffi_osx/x86/x86-ffi64.o -DMACOSX
Modules/_ctypes/libffi_osx/x86/x86-ffi64.c:615:0: warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
 #pragma clang diagnostic push
 ^
Modules/_ctypes/libffi_osx/x86/x86-ffi64.c:616:0: warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
 #pragma clang diagnostic ignored "-Wmissing-prototypes"
 ^
Modules/_ctypes/libffi_osx/x86/x86-ffi64.c:623:0: warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
 #pragma clang diagnostic pop
 ^
gcc -fno-strict-aliasing -I/Users/slabbe/Applications/sage-git/local/var/tmp/sage/build/python2-2.7.13.p1/include -DNDEBUG -g -fwrapv -O3 -Wall -Wno-unused -I_ctypes/darwin -I/Users/slabbe/Applications/sage-git/local/var/tmp/sage/build/python2-2.7.13.p1/src/Modules/_ctypes/libffi_osx/include -I/Users/slabbe/Applications/sage-git/local/var/tmp/sage/build/python2-2.7.13.p1/src/Modules/_ctypes/libffi_osx/powerpc -I/Users/slabbe/Applications/sage-git/local/include -I. -IInclude -I./Include -I/usr/local/include -I/Users/slabbe/Applications/sage-git/local/var/tmp/sage/build/python2-2.7.13.p1/src/Include -I/Users/slabbe/Applications/sage-git/local/var/tmp/sage/build/python2-2.7.13.p1/src -c /Users/slabbe/Applications/sage-git/local/var/tmp/sage/build/python2-2.7.13.p1/src/Modules/_ctypes/libffi_osx/powerpc/ppc-darwin.S -o build/temp.macosx-10.9-x86_64-2.7/Users/slabbe/Applications/sage-git/local/var/tmp/sage/build/python2-2.7.13.p1/src/Modules/_ctypes/libffi_osx/powerpc/ppc-darwin.o -DMACOSX
...
Successfully installed python2-2.7.13.p1
...

[slabbe]

But if I redo:

$ mv local/include/dispatch/object.h local/include/dispatch/object.h.no

then sage -f python2 gives (and we see that gcc is involved here, not clang):

...
building '_scproxy' extension
creating build/temp.macosx-10.9-x86_64-2.7/Mac
creating build/temp.macosx-10.9-x86_64-2.7/Mac/Modules
gcc -fno-strict-aliasing -I/Users/slabbe/Applications/sage-git/local/var/tmp/sage/build/python2-2.7.13.p1/include -DNDEBUG -g -fwrapv -O3 -Wall -Wno-unused -I/Users/slabbe/Applications/sage-git/local/include -I. -IInclude -I./Include -I/usr/local/include -I/Users/slabbe/Applications/sage-git/local/var/tmp/sage/build/python2-2.7.13.p1/src/Include -I/Users/slabbe/Applications/sage-git/local/var/tmp/sage/build/python2-2.7.13.p1/src -c ./Mac/Modules/_scproxy.c -o build/temp.macosx-10.9-x86_64-2.7/./Mac/Modules/_scproxy.o
In file included from /usr/include/dispatch/dispatch.h:51:0,
                 from /System/Library/Frameworks/CoreFoundation.framework/Headers/CFStream.h:15,
                 from /System/Library/Frameworks/CoreFoundation.framework/Headers/CFPropertyList.h:13,
                 from /System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:55,
                 from /System/Library/Frameworks/SystemConfiguration.framework/Headers/SystemConfiguration.h:29,
                 from ./Mac/Modules/_scproxy.c:6:
/usr/include/dispatch/object.h:143:15: error: expected identifier or '(' before '^' token
 typedef void (^dispatch_block_t)(void);
               ^
In file included from /usr/include/dispatch/dispatch.h:51:0,
                 from /System/Library/Frameworks/CoreFoundation.framework/Headers/CFStream.h:15,
                 from /System/Library/Frameworks/CoreFoundation.framework/Headers/CFPropertyList.h:13,
                 from /System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:55,
                 from /System/Library/Frameworks/SystemConfiguration.framework/Headers/SystemConfiguration.h:29,
                 from ./Mac/Modules/_scproxy.c:6:
/usr/include/dispatch/object.h:362:3: error: unknown type name 'dispatch_block_t'
   dispatch_block_t notification_block);
   ^
./Mac/Modules/_scproxy.c: In function 'get_proxy_settings':
./Mac/Modules/_scproxy.c:67:50: warning: the comparison will always evaluate as 'true' for the address of 'kSCPropNetProxiesExcludeSimpleHostnames' will never be NULL [-Waddress]
     if (&kSCPropNetProxiesExcludeSimpleHostnames != NULL) {
                                                  ^
building '_tkinter' extension
gcc -fno-strict-aliasing -I/Users/slabbe/Applications/sage-git/local/var/tmp/sage/build/python2-2.7.13.p1/include -DNDEBUG -g -fwrapv -O3 -Wall -Wno-unused -DWITH_APPINIT=1 -I/System/Library/Frameworks/Tcl.framework/Headers -I/System/Library/Frameworks/Tcl.framework/Versions/Current/PrivateHeaders -I/System/Library/Frameworks/Tk.framework/Headers -I/System/Library/Frameworks/Tk.framework/Versions/Current/PrivateHeaders -I/usr/X11R6/include -I/Users/slabbe/Applications/sage-git/local/include -I. -IInclude -I./Include -I/usr/local/include -I/Users/slabbe/Applications/sage-git/local/var/tmp/sage/build/python2-2.7.13.p1/src/Include -I/Users/slabbe/Applications/sage-git/local/var/tmp/sage/build/python2-2.7.13.p1/src -c /Users/slabbe/Applications/sage-git/local/var/tmp/sage/build/python2-2.7.13.p1/src/Modules/_tkinter.c -o build/temp.macosx-10.9-x86_64-2.7/Users/slabbe/Applications/sage-git/local/var/tmp/sage/build/python2-2.7.13.p1/src/Modules/_tkinter.o -framework Tk
Modules/_tkinter.c: In function 'AsObj':
Modules/_tkinter.c:1178:38: warning: passing argument 1 of 'Tcl_NewUnicodeObj' from incompatible pointer type
             return Tcl_NewUnicodeObj(inbuf, size);
                                      ^
In file included from /System/Library/Frameworks/Tcl.framework/Headers/tcl.h:2246:0,
                 from Modules/_tkinter.c:70:/System/Library/Frameworks/Tcl.framework/Headers/tclDecls.h:2238:18: note: expected 'const Tcl_UniChar *' but argument is of type 'Py_UNICODE *' EXTERN Tcl_Obj * Tcl_NewUnicodeObj(CONST Tcl_UniChar *unicode,                  ^gcc -fno-strict-aliasing -I/Users/slabbe/Applications/sage-git/local/var/tmp/sage/build/python2-2.7.13.p1/include -DNDEBUG -g -fwrapv -O3 -Wall -Wno-unused -DWITH_APPINIT=1 -I/System/Library/Frameworks/Tcl.framework/Headers -I/System/Library/Frameworks/Tcl.framework/Versions/Current/PrivateHeaders -I/System/Library/Frameworks/Tk.framework/Headers -I/System/Library/Frameworks/Tk.framework/Versions/Current/PrivateHeaders -I/usr/X11R6/include -I/Users/slabbe/Applications/sage-git/local/include -I. -IInclude -I./Include -I/usr/local/include -I/Users/slabbe/Applications/sage-git/local/var/tmp/sage/build/python2-2.7.13.p1/src/Include -I/Users/slabbe/Applications/sage-git/local/var/tmp/sage/build/python2-2.7.13.p1/src -c /Users/slabbe/Applications/sage-git/local/var/tmp/sage/build/python2-2.7.13.p1/src/Modules/tkappinit.c -o build/temp.macosx-10.9-x86_64-2.7/Users/slabbe/Applications/sage-git/local/var/tmp/sage/build/python2-2.7.13.p1/src/Modules/tkappinit.o -framework Tk
gcc -bundle -undefined dynamic_lookup -L/Users/slabbe/Applications/sage-git/local/lib -Wl,-rpath,/Users/slabbe/Applications/sage-git/local/lib -L/Users/slabbe/Applications/sage-git/local/lib -Wl,-rpath,/Users/slabbe/Applications/sage-git/local/lib -fno-strict-aliasing -I/Users/slabbe/Applications/sage-git/local/var/tmp/sage/build/python2-2.7.13.p1/include -DNDEBUG -g -fwrapv -O3 -Wall -Wno-unused build/temp.macosx-10.9-x86_64-2.7/Users/slabbe/Applications/sage-git/local/var/tmp/sage/build/python2-2.7.13.p1/src/Modules/_tkinter.o build/temp.macosx-10.9-x86_64-2.7/Users/slabbe/Applications/sage-git/local/var/tmp/sage/build/python2-2.7.13.p1/src/Modules/tkappinit.o -L/Users/slabbe/Applications/sage-git/local/lib -L/usr/local/lib -L. -o build/lib.macosx-10.9-x86_64-2.7/_tkinter.so -framework Tcl -framework Tk
building '_ctypes' extension
...
************************************************************************
Error installing package python2-2.7.13.p1
************************************************************************
...

[fbissey]

Hum, from spkg-install for python2

    if [ $MACOSX_VERSION -ge 16 ]; then
        echo "OS X 10.$[$MACOSX_VERSION-4] Building with clang."
        CC=clang

so it is only built with clang on OS X 10.12 and over. Probably should be extended but it is a separate issue. The calls to clang in your build is when python2 needs an objective C compiler. This is set to clang in sage-env.