Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#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)

freebsd-cmake.log.gz (514.2 KB) - added by dimpase 3 years ago.
see failing test 298 (2nd try)
cmake-3.8.1.log (131.3 KB) - added by slabbe 3 years ago.
On OSX 10.10.2 Yosemite with XCode 6.3
make_qemu_image (5.4 KB) - added by tmonteil 3 years ago.

Download all attachments as: .zip

Change History (116)

comment:1 Changed 3 years ago by fbissey

  • Cc fbissey added

comment:2 Changed 3 years ago by 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?

comment:3 Changed 3 years ago by dimpase

  • Authors set to Dima Pasechnik
  • Dependencies set to u/dimpase/cmakeupd
  • Status changed from new to needs_info

comment:4 Changed 3 years ago by dimpase

  • Branch set to u/dimpase/cmakeupd
  • Commit set to addf5a7f264cc0ee8e4e5b1857eff92bf621c9de
  • Dependencies u/dimpase/cmakeupd deleted

New commits:

addf5a7cmake update to 3.8.1

comment:5 Changed 3 years ago by 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.

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

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

comment:8 Changed 3 years ago by 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 :-)

comment:9 Changed 3 years ago by 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.

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

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

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

comment:13 Changed 3 years ago by fbissey

  • 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:

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

comment:14 Changed 3 years ago by dimpase

  • 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 3 years ago by 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...

comment:16 Changed 3 years ago by 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.

comment:18 follow-up: Changed 3 years ago by dimpase

  • 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 3 years ago by 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.

comment:20 Changed 3 years ago by 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.

comment:21 Changed 3 years ago by fbissey

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

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

comment:23 Changed 3 years ago by git

  • Commit changed from 325196871a69703ede67aca5b85b5f5f6785f09c to 43aec08aad49fe98bc2d79e74b71836b3dcc8403

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

43aec08make an exception for freeBSD

comment:24 Changed 3 years ago by fbissey

Alright! Can you test with that last commit please.

Changed 3 years ago by dimpase

see failing test 298 (2nd try)

comment:25 Changed 3 years ago by dimpase

nope, still the same test that is failing

comment:26 Changed 3 years ago by git

  • Commit changed from 43aec08aad49fe98bc2d79e74b71836b3dcc8403 to 8fbe406aa71fbeeeb07477f307e98cc71c56a15b

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

8fbe406make exception for correct OS, FreeBSD not Darwin.

comment:27 Changed 3 years ago by fbissey

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

comment:28 Changed 3 years ago by dimpase

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

comment:29 Changed 3 years ago by tmonteil

  • 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 3 years ago by 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
Last edited 3 years ago by slabbe (previous) (diff)

Changed 3 years ago by slabbe

On OSX 10.10.2 Yosemite with XCode 6.3

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

Last edited 3 years ago by slabbe (previous) (diff)

comment:32 follow-up: Changed 3 years ago by slabbe

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

comment:33 Changed 3 years ago by tmonteil

  • Branch changed from u/fbissey/cmakeupd to u/tmonteil/cmakeupd

comment:34 in reply to: ↑ 32 Changed 3 years ago by tmonteil

  • Commit changed from 8fbe406aa71fbeeeb07477f307e98cc71c56a15b to 15d1b3566e74ae8e832385d21685a88155d2bb13

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.

comment:35 Changed 3 years ago by tmonteil

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

comment:36 Changed 3 years ago by 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....

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

comment:38 Changed 3 years ago by tmonteil

  • Cc isuruf added

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

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

comment:40 Changed 3 years ago by git

  • 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 3 years ago by 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 ?) ?

comment:42 in reply to: ↑ 39 ; follow-up: Changed 3 years ago by 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.

comment:43 follow-up: Changed 3 years ago by 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.

comment:44 Changed 3 years ago by 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.

comment:45 follow-up: Changed 3 years ago by 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.

comment:46 Changed 3 years ago by git

  • 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 3 years ago by tmonteil

Replying to slabbe:

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

Patch updated.

comment:48 Changed 3 years ago by tmonteil

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

comment:49 Changed 3 years ago by 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.

Last edited 3 years ago by slabbe (previous) (diff)

comment:50 follow-up: Changed 3 years ago by 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.

comment:51 Changed 3 years ago by git

  • Commit changed from f5ce853024e444bc29680e935e3a8435e7f4a486 to ef2291b63e154205a5f5586fb04b5bef925b5e1b

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

8de5fc7Trac #22999 : rewrite osx10.10.patch for cmake 3.8.1.
5ca4ce5Trac #22999 : update osx10.10.patch w.r.t. comment 39.
ef2291bTrac #22999 : update osx10.10.patch w.r.t. comment 45.

comment:52 in reply to: ↑ 50 Changed 3 years ago by 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.

comment:53 in reply to: ↑ 43 Changed 3 years ago by 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.

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

comment:55 follow-up: Changed 3 years ago by 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.

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

comment:57 in reply to: ↑ 55 Changed 3 years ago by 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...

comment:58 Changed 3 years ago by 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.

comment:59 Changed 3 years ago by 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
$
Last edited 3 years ago by slabbe (previous) (diff)

comment:60 Changed 3 years ago by fbissey

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

comment:61 Changed 3 years ago by 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.

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

comment:63 Changed 3 years ago by 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.

comment:64 Changed 3 years ago by 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 
Last edited 3 years ago by slabbe (previous) (diff)

comment:65 Changed 3 years ago by slabbe

  • Keywords thursdaysbdx added
Last edited 3 years ago by slabbe (previous) (diff)

comment:66 in reply to: ↑ 42 Changed 3 years ago by 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?

comment:67 Changed 3 years ago by 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.

comment:68 follow-up: Changed 3 years ago by 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.

comment:69 in reply to: ↑ 68 Changed 3 years ago by 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)

comment:70 Changed 3 years ago by 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.

comment:71 Changed 3 years ago by dimpase

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

comment:72 Changed 3 years ago by dimpase

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 3 years ago by 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.

comment:74 Changed 3 years ago by slabbe

On OSX 10.10, deleting file build/pkgs/cmake/patches/osx10.10.patch and with this modif on top of the current branch:

  • 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  
    11#!/usr/bin/env bash
    22
     3if [ "$UNAME" = Darwin ]; then
     4    CC=clang
     5    #CXX=clang++
     6fi
     7
    38cd src
    49
    510./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  
    11#!/usr/bin/env bash
    22
     3if [ "$UNAME" = Darwin ]; then
     4    CC=clang
     5    CXX=clang++
     6fi
     7
    38cd src
    49
    510./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.

Last edited 3 years ago by slabbe (previous) (diff)

comment:75 Changed 3 years ago by 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.

comment:76 follow-up: Changed 3 years ago by 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

comment:77 Changed 3 years ago by slabbe

  • Branch changed from u/tmonteil/cmakeupd to u/slabbe/cmakeupd
  • Commit changed from ef2291b63e154205a5f5586fb04b5bef925b5e1b to 07543417c56eccca464077371644ff147f181444

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


New commits:

3c4d94eMerge branch 'u/tmonteil/cmakeupd' of trac.sagemath.org:sage into 8.0.beta7
075434122999: Using CC=clang and CXX=clang++ on Darwin

comment:78 in reply to: ↑ 76 Changed 3 years ago by 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.

comment:79 Changed 3 years ago by git

  • Commit changed from 07543417c56eccca464077371644ff147f181444 to 0a16efcb77eeba1977361c6f6c268e7db6edd60a

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

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

comment:80 Changed 3 years ago by slabbe

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

comment:82 Changed 3 years ago by 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
...

comment:83 Changed 3 years ago by 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
Last edited 3 years ago by slabbe (previous) (diff)

comment:84 Changed 3 years ago by 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?

comment:85 Changed 3 years ago by 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.

comment:86 Changed 3 years ago by 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.

comment:87 follow-up: Changed 3 years ago by slabbe

  • 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?

Last edited 3 years ago by slabbe (previous) (diff)

comment:88 in reply to: ↑ 87 Changed 3 years ago by 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.

comment:89 Changed 3 years ago by slabbe

  • Authors changed from Dima Pasechnik to Dima Pasechnik, François Bissey, Thierry Monteil

comment:90 Changed 3 years ago by git

  • Commit changed from 0a16efcb77eeba1977361c6f6c268e7db6edd60a to 40dc98701432c8bd4e3165fcdf8e77b83becf903

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

40dc98722999: cmake pkg type from optional to experimental

comment:91 Changed 3 years ago by fbissey

That commit comment is backwards :)

comment:92 Changed 3 years ago by git

  • Commit changed from 40dc98701432c8bd4e3165fcdf8e77b83becf903 to 719acc302e533f123bc0d738bc82a0a436da89bc

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

719acc322999: cmake pkg type from optional to experimental

comment:93 Changed 3 years ago by git

  • Commit changed from 719acc302e533f123bc0d738bc82a0a436da89bc to a4ad8d40e86e0d417226d809d1eb5f928be49c85

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

a4ad8d422999: cmake pkg type from experimental to optional

comment:94 Changed 3 years ago by slabbe

  • 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 3 years ago by fbissey

  • 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 3 years ago by tmonteil

  • 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 3 years ago by 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]

comment:98 follow-up: Changed 3 years ago by 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?

comment:99 in reply to: ↑ 98 Changed 3 years ago by 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

comment:100 Changed 3 years ago by 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.

comment:101 Changed 3 years ago by 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.

comment:102 Changed 3 years ago by fbissey

  • 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:

a307700skip over BundleUtilities test has it is broken on some platforms

comment:103 follow-up: Changed 3 years ago by 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?

comment:104 in reply to: ↑ 103 Changed 3 years ago by 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

Changed 3 years ago by tmonteil

comment:105 Changed 3 years ago by tmonteil

  • 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 3 years ago by vbraun

  • Branch changed from u/fbissey/cmakeupd to a307700da45d6c8552014e0f4715eeecaa3b3c02
  • Resolution set to fixed
  • Status changed from positive_review to closed

comment:107 Changed 3 years ago by slabbe

  • Commit a307700da45d6c8552014e0f4715eeecaa3b3c02 deleted

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)

comment:108 follow-up: Changed 3 years ago by fbissey

Aren't you building python with clang?

comment:109 in reply to: ↑ 108 Changed 3 years ago by 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] ****************************************************
...

comment:110 Changed 3 years ago by 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.

comment:111 Changed 3 years ago by 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
...
Last edited 3 years ago by slabbe (previous) (diff)

comment:112 Changed 3 years ago by 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
************************************************************************
...

comment:113 Changed 3 years ago by 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.

Note: See TracTickets for help on using tickets.