View Issue Details Jump to Notes ] Print ]
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.
Attached Filespatch file icon 0002-Searched-for-Carbon-and-remove-unnecessary-uses.patch [^] (3,780 bytes) 2016-03-17 10:49 [Show Content]

 Relationships

  Notes
(0040707)
Sean McBride (reporter)
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 (reporter)
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 (reporter)
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 (reporter)
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 (manager)
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 (manager)
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 (manager)
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 (manager)
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 (reporter)
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 (manager)
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 (reporter)
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 (reporter)
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 (reporter)
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 (manager)
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 (manager)
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 (reporter)
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 (reporter)
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 (administrator)
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.

 Issue History
Date Modified Username Field Change
2016-03-16 14:14 Erik Schnetter New Issue
2016-03-17 00:19 Sean McBride Note Added: 0040707
2016-03-17 09:30 Erik Schnetter Note Added: 0040712
2016-03-17 10:49 Sean McBride File Added: 0002-Searched-for-Carbon-and-remove-unnecessary-uses.patch
2016-03-17 10:52 Sean McBride Note Added: 0040717
2016-03-17 13:25 Erik Schnetter Note Added: 0040718
2016-03-17 14:55 Brad King Note Added: 0040719
2016-03-17 14:56 Brad King Note Added: 0040720
2016-03-18 10:00 Brad King Note Added: 0040723
2016-03-18 10:00 Brad King Assigned To => Brad King
2016-03-18 10:00 Brad King Status new => resolved
2016-03-18 10:00 Brad King Resolution open => fixed
2016-03-18 10:00 Brad King Fixed in Version => CMake 3.6
2016-03-18 10:00 Brad King Target Version => CMake 3.6
2016-03-18 10:23 Brad King Note Added: 0040724
2016-03-18 10:59 Sean McBride Note Added: 0040725
2016-03-18 11:13 Brad King Note Added: 0040726
2016-03-18 12:05 Erik Schnetter Note Added: 0040728
2016-03-18 13:12 Sean McBride Note Added: 0040730
2016-03-18 13:24 Sean McBride Note Added: 0040731
2016-03-18 13:34 Brad King Note Added: 0040732
2016-03-18 13:38 Brad King Note Added: 0040733
2016-03-18 14:10 Erik Schnetter Note Added: 0040734
2016-03-22 16:43 Sean McBride Note Added: 0040755
2016-06-10 14:21 Kitware Robot Note Added: 0041215
2016-06-10 14:21 Kitware Robot Status resolved => closed


Copyright © 2000 - 2018 MantisBT Team