#22999 closed enhancement (fixed)
update cmake to version 3.8.1
Reported by: | dimpase | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | sage-8.0 |
Component: | packages: optional | Keywords: | thursdaysbdx |
Cc: | fbissey, embray, slabbe, isuruf | Merged in: | |
Authors: | Dima Pasechnik, François Bissey, Thierry Monteil | Reviewers: | Sébastien Labbé |
Report Upstream: | Reported upstream. Developers acknowledge bug. | Work issues: | |
Branch: | a307700 (Commits) | Commit: | |
Dependencies: | Stopgaps: |
Description
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
Attachments (3)
Change History (116)
comment:1 Changed 4 years ago by
- Cc fbissey added
comment:2 Changed 4 years ago by
comment:3 Changed 4 years ago by
- Dependencies set to u/dimpase/cmakeupd
- Status changed from new to needs_info
comment:4 Changed 4 years ago by
- Branch set to u/dimpase/cmakeupd
- Commit set to addf5a7f264cc0ee8e4e5b1857eff92bf621c9de
- Dependencies u/dimpase/cmakeupd deleted
New commits:
addf5a7 | cmake update to 3.8.1
|
comment:5 Changed 4 years ago by
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.
comment:6 Changed 4 years ago by
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?
comment:7 Changed 4 years ago by
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.
comment:8 Changed 4 years ago by
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 :-)
comment:9 Changed 4 years ago by
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.
comment:10 Changed 4 years ago by
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....
comment:11 Changed 4 years ago by
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.
comment:12 Changed 4 years ago by
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.
comment:13 Changed 4 years ago by
- Branch changed from u/dimpase/cmakeupd to u/fbissey/cmakeupd
- Commit changed from addf5a7f264cc0ee8e4e5b1857eff92bf621c9de to 325196871a69703ede67aca5b85b5f5f6785f09c
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
|
comment:14 Changed 4 years ago by
- Cc embray added
I wonder how this would play out on cygwin. Potentially it might help avoid DLL clashes there, if it flies at all.
comment:15 Changed 4 years ago by
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
...
comment:16 Changed 4 years ago by
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.
comment:17 Changed 4 years ago by
comment:18 follow-up: ↓ 19 Changed 4 years ago by
- Report Upstream changed from N/A to Reported upstream. No feedback yet.
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?)
comment:19 in reply to: ↑ 18 Changed 4 years ago by
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.
comment:20 Changed 4 years ago by
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.
comment:21 Changed 4 years ago by
What does UNAME
get set to on freeBSD? I could skip the test based on OS.
comment:22 Changed 4 years ago by
$ 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
comment:23 Changed 4 years ago by
- Commit changed from 325196871a69703ede67aca5b85b5f5f6785f09c to 43aec08aad49fe98bc2d79e74b71836b3dcc8403
Branch pushed to git repo; I updated commit sha1. New commits:
43aec08 | make an exception for freeBSD
|
comment:24 Changed 4 years ago by
Alright! Can you test with that last commit please.
comment:25 Changed 4 years ago by
nope, still the same test that is failing
comment:26 Changed 4 years ago by
- Commit changed from 43aec08aad49fe98bc2d79e74b71836b3dcc8403 to 8fbe406aa71fbeeeb07477f307e98cc71c56a15b
Branch pushed to git repo; I updated commit sha1. New commits:
8fbe406 | make exception for correct OS, FreeBSD not Darwin.
|
comment:27 Changed 4 years ago by
I am a dummy. I copy pasted from somewhere but forgot to change the essential bit identifying freeBSD. Should work now.
comment:28 Changed 4 years ago by
All the selftests now pass on FreeBSD. How about OSX?
comment:29 Changed 4 years ago by
- Cc slabbe added
Note that the current cmake 3.8.0 does not build on OSX, see https://trac.sagemath.org/ticket/22817#comment:9
comment:30 Changed 4 years ago by
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
comment:31 Changed 4 years ago by
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
comment:32 follow-up: ↓ 34 Changed 4 years ago by
I tried to reuse the same osx10.10.patch
, but it does not apply on cmake-3.8.1
anymore.
comment:33 Changed 4 years ago by
- Branch changed from u/fbissey/cmakeupd to u/tmonteil/cmakeupd
comment:34 in reply to: ↑ 32 Changed 4 years ago by
- Commit changed from 8fbe406aa71fbeeeb07477f307e98cc71c56a15b to 15d1b3566e74ae8e832385d21685a88155d2bb13
comment:35 Changed 4 years ago by
FWIW, the current branch compiles and self-tests pass on my x86_64 laptop.
comment:36 Changed 4 years ago by
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....
comment:37 Changed 4 years ago by
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>
comment:38 Changed 4 years ago by
- Cc isuruf added
Adding Isuru Fernando who wrote the first OSX patch in CC.
comment:39 follow-ups: ↓ 41 ↓ 42 Changed 4 years ago by
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.
comment:40 Changed 4 years ago by
- Commit changed from 15d1b3566e74ae8e832385d21685a88155d2bb13 to 3a48f272dba4fbc693eaf77db69c9adb4cc9af93
Branch pushed to git repo; I updated commit sha1. New commits:
3a48f27 | #21668 : update osx10.10.patch w.r.t. comment 39.
|
comment:41 in reply to: ↑ 39 Changed 4 years ago by
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 ?) ?
comment:42 in reply to: ↑ 39 ; follow-up: ↓ 66 Changed 4 years ago by
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.
comment:43 follow-up: ↓ 53 Changed 4 years ago by
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.
comment:44 Changed 4 years ago by
... 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.
comment:45 follow-up: ↓ 47 Changed 4 years ago by
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.
comment:46 Changed 4 years ago by
- Commit changed from 3a48f272dba4fbc693eaf77db69c9adb4cc9af93 to f5ce853024e444bc29680e935e3a8435e7f4a486
Branch pushed to git repo; I updated commit sha1. New commits:
f5ce853 | #21668 : update osx10.10.patch w.r.t. comment 45.
|
comment:47 in reply to: ↑ 45 Changed 4 years ago by
Replying to slabbe:
Therefore, the
CFBundle.h
orCFString.h
both work. But#include <algorithm>
seems to be necessary.
Patch updated.
comment:48 Changed 4 years ago by
Could you also test with sage -f -c cmake
to see if self-tests pass ?
comment:49 Changed 4 years ago by
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.
comment:50 follow-up: ↓ 52 Changed 4 years ago by
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.
comment:51 Changed 4 years ago by
- Commit changed from f5ce853024e444bc29680e935e3a8435e7f4a486 to ef2291b63e154205a5f5586fb04b5bef925b5e1b
comment:52 in reply to: ↑ 50 Changed 4 years ago by
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.
comment:53 in reply to: ↑ 43 Changed 4 years ago by
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.
comment:54 Changed 4 years ago by
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
comment:55 follow-up: ↓ 57 Changed 4 years ago by
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.
comment:56 Changed 4 years ago by
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
comment:57 in reply to: ↑ 55 Changed 4 years ago by
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...
comment:58 Changed 4 years ago by
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.
comment:59 Changed 4 years ago by
$ 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 $
comment:60 Changed 4 years ago by
By the way how did it get there? What installed it?
comment:61 Changed 4 years ago by
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.
comment:62 Changed 4 years ago by
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
comment:63 Changed 4 years ago by
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.
comment:64 Changed 4 years ago by
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
comment:65 Changed 4 years ago by
- Keywords thursdaysbdx added
comment:66 in reply to: ↑ 42 Changed 4 years ago by
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++ fiThat 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
?
comment:67 Changed 4 years ago by
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.
comment:68 follow-up: ↓ 69 Changed 4 years ago by
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.
comment:69 in reply to: ↑ 68 Changed 4 years ago by
Replying to jhpalmieri:
I originally tried with just
CC=clang
but the build failed. It succeeded when I addedCXX=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)
comment:70 Changed 4 years ago by
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.
comment:71 Changed 4 years ago by
I think we should go with clang on OSX, full stop. What else is holding up this?
comment:72 Changed 4 years ago by
I can provide accounts on a 32-bit system (arando buildbot) for anyone who wants to do a 32-bit Linux test.
comment:73 Changed 4 years ago by
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.
comment:74 Changed 4 years ago by
Deleting file build/pkgs/cmake/patches/osx10.10.patch
and with this modif:
-
build/pkgs/cmake/spkg-install
diff --git a/build/pkgs/cmake/spkg-install b/build/pkgs/cmake/spkg-install index 413effc..93579b9 100755
a b 1 1 #!/usr/bin/env bash 2 2 3 if [ "$UNAME" = Darwin ]; then 4 CC=clang 5 #CXX=clang++ 6 fi 7 3 8 cd src 4 9 5 10 ./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
diff --git a/build/pkgs/cmake/spkg-install b/build/pkgs/cmake/spkg-install index 413effc..d3e5ab9 100755
a b 1 1 #!/usr/bin/env bash 2 2 3 if [ "$UNAME" = Darwin ]; then 4 CC=clang 5 CXX=clang++ 6 fi 7 3 8 cd src 4 9 5 10 ./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.
comment:75 Changed 4 years ago by
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.
comment:76 follow-up: ↓ 78 Changed 4 years ago by
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
comment:77 Changed 4 years ago by
- Branch changed from u/tmonteil/cmakeupd to u/slabbe/cmakeupd
- Commit changed from ef2291b63e154205a5f5586fb04b5bef925b5e1b to 07543417c56eccca464077371644ff147f181444
comment:78 in reply to: ↑ 76 Changed 4 years ago by
Replying to slabbe:
With
CC=clang
andCXX=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 CTestFailed 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.
comment:79 Changed 4 years ago by
- Commit changed from 07543417c56eccca464077371644ff147f181444 to 0a16efcb77eeba1977361c6f6c268e7db6edd60a
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
|
comment:80 Changed 4 years ago by
Will rerun sage -f -c cmake
on my osx 10.10 overnight and will report back tomorrow.
comment:81 Changed 4 years ago by
I think the redefinition failure is due to, https://github.com/sagemath/sage/blob/8.0.beta8/build/pkgs/gcc/spkg-install#L67-L68
comment:82 Changed 4 years ago by
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 ...
comment:83 Changed 4 years ago by
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
comment:84 Changed 4 years ago by
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?
comment:85 Changed 4 years ago by
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.
comment:86 Changed 4 years ago by
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.
comment:87 follow-up: ↓ 88 Changed 4 years ago by
- Reviewers set to Sébastien Labbé
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?
comment:88 in reply to: ↑ 87 Changed 4 years ago by
Replying to slabbe:
What about
- keeping the sed of the gcc
spkg-install
patching thelocal/include/dispatch/object.h
- keeping the osx 10.10 patch for cmake-3.8.1
- keeping
C=clang
andCXX=clang++
for cmakespkg-install
andspkg-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.
comment:89 Changed 4 years ago by
comment:90 Changed 4 years ago by
- Commit changed from 0a16efcb77eeba1977361c6f6c268e7db6edd60a to 40dc98701432c8bd4e3165fcdf8e77b83becf903
Branch pushed to git repo; I updated commit sha1. New commits:
40dc987 | 22999: cmake pkg type from optional to experimental
|
comment:91 Changed 4 years ago by
That commit comment is backwards :)
comment:92 Changed 4 years ago by
- Commit changed from 40dc98701432c8bd4e3165fcdf8e77b83becf903 to 719acc302e533f123bc0d738bc82a0a436da89bc
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
|
comment:93 Changed 4 years ago by
- Commit changed from 719acc302e533f123bc0d738bc82a0a436da89bc to a4ad8d40e86e0d417226d809d1eb5f928be49c85
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
|
comment:94 Changed 4 years ago by
- Status changed from needs_info to needs_review
...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*.
comment:95 Changed 4 years ago by
- Report Upstream changed from Reported upstream. No feedback yet. to Reported upstream. Developers acknowledge bug.
- Status changed from needs_review to positive_review
I am happy with the content of the ticket. Positive review.
comment:96 Changed 4 years ago by
- Status changed from positive_review to needs_info
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.
comment:97 Changed 4 years ago by
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]
comment:98 follow-up: ↓ 99 Changed 4 years ago by
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?
comment:99 in reply to: ↑ 98 Changed 4 years ago by
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
comment:100 Changed 4 years ago by
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.
comment:101 Changed 4 years ago by
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.
comment:102 Changed 4 years ago by
- Branch changed from u/slabbe/cmakeupd to u/fbissey/cmakeupd
- Commit changed from a4ad8d40e86e0d417226d809d1eb5f928be49c85 to a307700da45d6c8552014e0f4715eeecaa3b3c02
- Status changed from needs_info to needs_review
OK "fix" is in.
New commits:
a307700 | skip over BundleUtilities test has it is broken on some platforms
|
comment:103 follow-up: ↓ 104 Changed 4 years ago by
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?
comment:104 in reply to: ↑ 103 Changed 4 years ago by
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
Changed 4 years ago by
comment:105 Changed 4 years ago by
- Status changed from needs_review to positive_review
[cmake-3.8.1] 100% tests passed, 0 tests failed out of 442
Thanks !
comment:106 Changed 4 years ago by
- Branch changed from u/fbissey/cmakeupd to a307700da45d6c8552014e0f4715eeecaa3b3c02
- Resolution set to fixed
- Status changed from positive_review to closed
comment:107 Changed 4 years ago by
- Commit a307700da45d6c8552014e0f4715eeecaa3b3c02 deleted
What about
- keeping the sed of the gcc
spkg-install
patching thelocal/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)
comment:108 follow-up: ↓ 109 Changed 4 years ago by
Aren't you building python
with clang
?
comment:109 in reply to: ↑ 108 Changed 4 years ago by
Replying to fbissey:
Aren't you building
python
withclang
?
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] **************************************************** ...
comment:110 Changed 4 years ago by
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.
comment:111 Changed 4 years ago by
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 ...
comment:112 Changed 4 years ago by
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 ************************************************************************ ...
comment:113 Changed 4 years ago by
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.
with SAGE_CHECK=yes I get, on Gentoo Linux,
which probably can be ignored, as this is something GTK-specific?