MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0016021CMakeCMakepublic2016-03-16 14:142016-06-10 14:21
ReporterErik Schnetter 
Assigned ToBrad King 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformApple MacOSOS XOS Version10.4.10
Product VersionCMake 3.5 
Target VersionCMake 3.6Fixed in VersionCMake 3.6 
Summary0016021: Cannot build on OS X with GCC
DescriptionI cannot build cmake 3.5.0 on OS X "El Capitan" with GCC 5.3. After configuring normally, the build aborts with an error message. It seems that cmake uses some system header files with Apple-specific extensions that GCC cannot handle.

These extensions seem to have to do with the user interface; if so, there should be an option to not build the parts that cannot be built, and still build the "regular" cmake.

cmake 3.4.3 builds fine with the same setup.
Steps To ReproduceInstall GCC 5.3 via MacPorts; make GCC the default compiler

tar xzf cmake-3.5.0.tar.gz
cd cmake-3.5.0
# Building without the OpenSSL flag aborts with an error
./configure -- -DCMAKE_USE_OPENSSL=ON
gmake
Additional InformationThe build aborts with

[ 85%] Building CXX object Source/CMakeFiles/CPackLib.dir/CPack/cmCPackDragNDropGenerator.cxx.o
In file included from /usr/include/Availability.h:168:0,
                 from /usr/include/inttypes.h:224,
                 from /tmp/cmake-3.5.0/Utilities/KWIML/include/kwiml/int.h:194,
                 from /tmp/cmake-3.5.0/Utilities/cm_kwiml.h:22,
                 from /tmp/cmake-3.5.0/Source/cmStandardIncludes.h:34,
                 from /tmp/cmake-3.5.0/Source/cmObject.h:15,
                 from /tmp/cmake-3.5.0/Source/CPack/cmCPackGenerator.h:16,
                 from /tmp/cmake-3.5.0/Source/CPack/cmCPackDragNDropGenerator.h:16,
                 from /tmp/cmake-3.5.0/Source/CPack/cmCPackDragNDropGenerator.cxx:13:
/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Headers/LSInfoDeprecated.h:1242:34: error: expected '}' before '__attribute__'
   kLSHandlerOptionsDefault __OSX_AVAILABLE_BUT_DEPRECATED_MSG(__MAC_10_4, __MAC_10_11, __IPHONE_4_0, __IPHONE_9_0, "Creator codes are deprecated on OS X.") = 0,
                                  ^
In file included from /System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Headers/LSInfo.h:529:0,
                 from /System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Headers/LaunchServices.h:27,
                 from /System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:39,
                 from /System/Library/Frameworks/Carbon.framework/Headers/Carbon.h:20,
                 from /tmp/cmake-3.5.0/Source/CPack/cmCPackDragNDropGenerator.cxx:34:
/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Headers/LSInfoDeprecated.h:1242:163: error: expected unqualified-id before '=' token
   kLSHandlerOptionsDefault __OSX_AVAILABLE_BUT_DEPRECATED_MSG(__MAC_10_4, __MAC_10_11, __IPHONE_4_0, __IPHONE_9_0, "Creator codes are deprecated on OS X.") = 0,
                                                                                                                                                                   ^
/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Headers/LSInfoDeprecated.h:1294:1: error: expected declaration before '}' token
 }
 ^
Source/CMakeFiles/CPackLib.dir/build.make:518: recipe for target 'Source/CMakeFiles/CPackLib.dir/CPack/cmCPackDragNDropGenerator.cxx.o' failed
gmake[2]: *** [Source/CMakeFiles/CPackLib.dir/CPack/cmCPackDragNDropGenerator.cxx.o] Error 1
CMakeFiles/Makefile2:2018: recipe for target 'Source/CMakeFiles/CPackLib.dir/all' failed
gmake[1]: *** [Source/CMakeFiles/CPackLib.dir/all] Error 2
Makefile:160: recipe for target 'all' failed
gmake: *** [all] Error 2
TagsNo tags attached.
Relationships
Attached Filespatch 0002-Searched-for-Carbon-and-remove-unnecessary-uses.patch (3,780) 2016-03-17 10:49
https://public.kitware.com/Bug/file/5648/0002-Searched-for-Carbon-and-remove-unnecessary-uses.patch
Issue History
Date ModifiedUsernameFieldChange
2016-03-16 14:14Erik SchnetterNew Issue
2016-03-17 00:19Sean McBrideNote Added: 0040707
2016-03-17 09:30Erik SchnetterNote Added: 0040712
2016-03-17 10:49Sean McBrideFile Added: 0002-Searched-for-Carbon-and-remove-unnecessary-uses.patch
2016-03-17 10:52Sean McBrideNote Added: 0040717
2016-03-17 13:25Erik SchnetterNote Added: 0040718
2016-03-17 14:55Brad KingNote Added: 0040719
2016-03-17 14:56Brad KingNote Added: 0040720
2016-03-18 10:00Brad KingNote Added: 0040723
2016-03-18 10:00Brad KingAssigned To => Brad King
2016-03-18 10:00Brad KingStatusnew => resolved
2016-03-18 10:00Brad KingResolutionopen => fixed
2016-03-18 10:00Brad KingFixed in Version => CMake 3.6
2016-03-18 10:00Brad KingTarget Version => CMake 3.6
2016-03-18 10:23Brad KingNote Added: 0040724
2016-03-18 10:59Sean McBrideNote Added: 0040725
2016-03-18 11:13Brad KingNote Added: 0040726
2016-03-18 12:05Erik SchnetterNote Added: 0040728
2016-03-18 13:12Sean McBrideNote Added: 0040730
2016-03-18 13:24Sean McBrideNote Added: 0040731
2016-03-18 13:34Brad KingNote Added: 0040732
2016-03-18 13:38Brad KingNote Added: 0040733
2016-03-18 14:10Erik SchnetterNote Added: 0040734
2016-03-22 16:43Sean McBrideNote Added: 0040755
2016-06-10 14:21Kitware RobotNote Added: 0041215
2016-06-10 14:21Kitware RobotStatusresolved => closed

Notes
(0040707)
Sean McBride   
2016-03-17 00:19   
Can gcc 5.3 build a trivial .cxx file that includes only one/some of these:

#include <Availability.h>
#include <CoreFoundation/CoreFoundation.h>
#include <CoreServices/CoreServices.h>

If not, you're doomed: file a bug with gcc and switch to clang in the meantime. If it can parse those files, there's hope...

Still, there's some crud in cmake that I'll submit a patch for that may help you a bit...
(0040712)
Erik Schnetter   
2016-03-17 09:30   
The first two work fine, only the last leads to the problem:

$ cat>cc.cc
#include <Availability.h>
#include <CoreFoundation/CoreFoundation.h>
eschnett@Redshift:/tmp (08:15:48)
$ gcc -c cc.cc
eschnett@Redshift:/tmp (08:15:49)

(i.e. there's no error output from gcc.)
(0040717)
Sean McBride   
2016-03-17 10:52   
Erik, I would still file a bug with gcc. CoreServices.h is major system header. If gcc can't even parse it, it has little chance of building anything substantial.

Attached patch removes need for Carbon.h and replaces it with CoreServices.h (which is a subset), but it won't solve your problem.

If you comment out the CoreServices.h include and the one used function LocaleStringToLangAndRegionCodes(), does it build then?
(0040718)
Erik Schnetter   
2016-03-17 13:25   
Yes, these two changes make the code build.

The problematic lines are in a file "cmCPackDragNDropGenerator.cxx", which is part of "cpack". I am not interested in cpack -- I am only interested in cmake for building applications that others are distributing, not in distributing a package myself. Is there a way to disable building cpack?
(0040719)
Brad King   
2016-03-17 14:55   
Re 0016021:0040717: Thanks, Sean. I've applied part of that patch here:

  CPack: Avoid requiring Carbon framework on OS X
  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c718070c [^]

I'll later consider the Info.plist changes separately.
(0040720)
Brad King   
2016-03-17 14:56   
Re 0016021:0040718: There is no option to disable cpack and several parts of the code assume that the executable exists. We should strive to make it build with this compiler even if it means excluding some functionality.
(0040723)
Brad King   
2016-03-18 10:00   
I've made use of the CoreServices framework dependent on a check that the compiler can include the header:

 CPack: Avoid using OS X CoreServices if compiler fails on header
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=da808dc0 [^]
(0040724)
Brad King   
2016-03-18 10:23   
> # Building without the OpenSSL flag aborts with an error
> ./configure -- -DCMAKE_USE_OPENSSL=ON

FYI, one can build without OpenSSL by using system curl instead:

 ./bootstrap -- -DCMAKE_USE_SYSTEM_CURL=ON
(0040725)
Sean McBride   
2016-03-18 10:59   
Brad, might I suggest expanding the comments in that commit. OS X never doesn't have CoreServices, so checking for it is very odd, and the source code gives no clue as to why it's being done (only the commit message does).

Erik, I'm curious: why do you want to use a compiler that can't parse the system's headers? How well could such a compiler have been tested on that platform? Sounds pretty dubious to me.

As for OpenSSL, Apple considers it deprecated on their platform:

https://developer.apple.com/library/mac/documentation/Security/Conceptual/cryptoservices/GeneralPurposeCrypto/GeneralPurposeCrypto.html [^]

and it will be forever stuck on the old 0.9.8 branch. It might be a good idea to throw up a warning if someone tries to use system OpenSSL on OS X.
(0040726)
Brad King   
2016-03-18 11:13   
Re 0016021:0040725: Thanks. I revised the commit to add more comments and also produce a CMake-time warning in this case since it is not considered normal:

 CPack: Avoid using OS X CoreServices if compiler fails on header
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d84ba668 [^]
(0040728)
Erik Schnetter   
2016-03-18 12:05   
Sean:

- I want to build with GCC 5.3. This is a well-known high-quality compiler, and it works fine on OS X. I would not call it "dubious". There's an issue with compiling GUI code, but I'm not interested in that, and I'd happily disable the respective cmake features (if there was an option to do so). It used to be that using these features required using Objective-C and Objective-C++, and respective code is found in Apple's GUI development headers, so the nonstandard extensions are nothing new.

- cmake 3.4.3 builds fine with GCC 5.3 on OS X. Thus there isn't some fundamental issue with OS X, it's probably related to a new feature you introduced in the most recent cmake version. Note that the header you're including is marked "deprecated", and the cmake source code also explicitly says so.

- Why does cmake need to access GUI features? (The error is related to code handling drag-and-drop support.) I understand that some people prefer a GUI for cmake, but I really only want to use it on the command line. If it becomes difficult to build cmake on a system without a GUI, then I'm getting worried -- maybe it's time for a "cmake light" that only provides a command line interface? Note that the systems I'm using are usually only accessed remotely, via ssh, without GUI.

- I am building and installing OpenSSL 1.0.2g on OS X. While the system-provided library is outdated, that doesn't concern me.

- The reason I want to use GCC is that different C++ compilers offer different features and have different bugs, and are not completely binary compatible. I am experimenting with providing an identical build environment on many different platforms, so that I can shield my applications from having to deal with the (often inconsequential) differences between different systems. I thus want to make GCC 5.3 available everywhere, and cmake is part of that environment. See <https://github.com/LLNL/spack>. [^]
(0040730)
Sean McBride   
2016-03-18 13:12   
Brad, that's great thanks!

Erik, thanks. As I said, I was just curious. Just a couple of corrections though:
- the build error is not related to "GUI code" really. The CoreServices framework in fact doesn't do any GUI stuff. It's mostly file system, text encoding, and IPC stuff.
- the CoreServices framework is not wholesale deprecated. Parts of it are though.

Your error seems to come from an enum marked deprecated. Does this compile on gcc?

-----------
enum {
 foo = 1,
 bar __attribute__((deprecated)) = 2,
 baz = 3
};
-----------

clang does document that as an extension:
<http://clang.llvm.org/docs/LanguageExtensions.html#attributes-on-enumerators> [^]

maybe gcc doesn't support it?
(0040731)
Sean McBride   
2016-03-18 13:24   
Or more exactly, with the deprecation string:

enum {
 foo = 1,
 bar __attribute__((deprecated("Use baz instead"))) = 2,
 baz = 3
};
(0040732)
Brad King   
2016-03-18 13:34   
Re 0016021:0040731: I reproduced the error with GCC from Homebrew:

$ cat foo.cxx
enum {
  foo = 1,
  bar __attribute__((deprecated("Use baz instead"))) = 2,
  baz = 3
};

$ c++ --version
Apple LLVM version 7.0.2 (clang-700.1.81)
Target: x86_64-apple-darwin15.0.0
Thread model: posix

$ c++ -c foo.cxx

$ g++-5 --version
g++-5 (Homebrew gcc 5.3.0) 5.3.0

$ g++-5 -c foo.cxx
foo.cxx:3:7: error: expected '}' before '__attribute__'
   bar __attribute__((deprecated("Use baz instead"))) = 2,
       ^
foo.cxx:3:54: error: expected unqualified-id before '=' token
   bar __attribute__((deprecated("Use baz instead"))) = 2,
                                                      ^
foo.cxx:5:1: error: expected declaration before '}' token
 };
 ^
(0040733)
Brad King   
2016-03-18 13:38   
FWIW the OS X frameworks are aware of GCC 5.x and try to select a deprecation attribute compatible with it:

$ grep -A 1 __GNUC__ /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/Frameworks/Kernel.framework/Versions/Current/Headers/AvailabilityInternal.h
#elif defined(__GNUC__) && ((__GNUC__ >= 5) || ((__GNUC__ == 4) && (__GNUC_MINOR__ >= 5)))
    #define __AVAILABILITY_INTERNAL_DEPRECATED_MSG(_msg) __attribute__((deprecated(_msg)))

It must be this particular use site that is not supported. That should be addressed by the OS X framework developers for existing GCC versions that do not support this location of the __attribute__() syntax. Separately GCC should be taught to support it here. Both of these efforts are independent of CMake though.
(0040734)
Erik Schnetter   
2016-03-18 14:10   
I get:

$ cat enum.c
enum {
 foo = 1,
 bar __attribute__((deprecated)) = 2,
 baz = 3
};

eschnett@Redshift:/tmp (14:08:43)
$ gcc -c enum.c
enum.c:3:6: error: expected ',' or '}' before '__attribute__'
  bar __attribute__((deprecated)) = 2,
      ^

So it seem it's the location of the "__attribute__" identifier that causes the problem. While __attribute__ is probably an extension to the C standard, allowing attributes for enum identifiers seems quite natural to me. I'd hope that gcc allows this as well in the future!
(0040755)
Sean McBride   
2016-03-22 16:43   
I filed rdar://25298746 with Apple (alas, not a public database).

Erik, if you file a gcc bug, give me the URL and I'll pass it along to Apple.
(0041215)
Kitware Robot   
2016-06-10 14:21   
This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.