open-scene-graph build failure on 10.11: c++11-narrowing error

[apjanke]

open-scene-graph is failing to build for me on OS X 10.11.1 with Xcode 7.0 or 7.1.

This is for a plain HOMEBREW_MAKE_JOBS=1 brew install -v --build-from-source open-scene-graph, with no other options specified.

Build logs: https://gist.github.com/d52bf7d0cd9fa560fff6

[ 14%] Building CXX object src/osgDB/CMakeFiles/osgDB.dir/FileUtils.cpp.o
cd /tmp/open-scene-graph20151125-85762-o4wepw/OpenSceneGraph-3.4.0/build/src/osgDB && /usr/local/Library/ENV/4.3/clang++   -DDARWIN_IMAGEIO -DOSGDB_LIBRARY -DOSG_DEFAULT_LIBRARY_PATH=\"/usr/local/Cellar/open-scene-graph/3.4.0/lib/osgPlugins-3.4.0\" -DOSG_PLUGIN_EXTENSION=.so -DUSE_ZLIB -DosgDB_EXPORTS -I/tmp/open-scene-graph20151125-85762-o4wepw/OpenSceneGraph-3.4.0/include -F/Applications/Xcode-7.1.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/Frameworks -I/tmp/open-scene-graph20151125-85762-o4wepw/OpenSceneGraph-3.4.0/build/include  -std=c++11 -stdlib=libc++  -Wno-conversion -arch x86_64 -isysroot /Applications/Xcode-7.1.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk -fPIC   -x objective-c++ -o CMakeFiles/osgDB.dir/FileUtils.cpp.o -c /tmp/open-scene-graph20151125-85762-o4wepw/OpenSceneGraph-3.4.0/src/osgDB/FileUtils.cpp
In file included from /tmp/open-scene-graph20151125-85762-o4wepw/OpenSceneGraph-3.4.0/src/osgDB/FileUtils.cpp:888:
In file included from /Applications/Xcode-7.1.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:80:
In file included from /Applications/Xcode-7.1.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSURLCredential.h:9:
In file included from /Applications/Xcode-7.1.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/Frameworks/Security.framework/Headers/Security.h:74:
In file included from /Applications/Xcode-7.1.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/Frameworks/Security.framework/Headers/SecStaticCode.h:41:
/Applications/Xcode-7.1.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/Frameworks/Security.framework/Headers/CSCommon.h:200:32: error: enumerator value evaluates to -2147483648, which cannot be narrowed to type 'uint32_t' (aka 'unsigned int') [-Wc++11-narrowing]
    kSecCSConsiderExpiration = 1 << 31,         /* consider expired certificates invalid */
                               ^
1 error generated.
make[2]: *** [src/osgDB/CMakeFiles/osgDB.dir/FileUtils.cpp.o] Error 1
make[1]: *** [src/osgDB/CMakeFiles/osgDB.dir/all] Error 2
make: *** [all] Error 2

There are existing open issues for open-scene-graph – #44524 (OS version detection issue), #43536 (collada-dom dependency problem), #46356 (iconv link error) – but they look like they have different causes, so I'm opening a new one.

The weird thing is that this code looks like it's coming from one of Xcode's system-supplied headers, not open-scene-graph. Maybe that header is not clean with respect to the effective warning flags that open-scene-graph is compiling it with.

-Wc++11-narrowing is the warning group that's being triggered here. I don't know what in the formula or brew's superenv definition is enabling it and causing it to be an error.

[apjanke]

Adding ENV.append "CFLAGS", "-Wno-c++11-narrowing" to the formula didn't seem to have any effect. Does anyone know a good way to get the formula to pass -W flags to clang for a CMake-based build?

[apjanke]

Building OpenSceneGraph from its own distribution, outside Homebrew, is working for me on this same 10.11 box.

Here's the corresponding succeeding build command for FileUtils.cpp when built outside Homebrew.

cd /Users/janke/local/opp/openscenegraph/OpenSceneGraph/build/src/osgDB && /Applications/Xcode-7.1.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++   -DDARWIN_IMAGEIO -DOSGDB_LIBRARY -DOSG_DEFAULT_LIBRARY_PATH=\"/usr/local/lib/osgPlugins-3.5.1\" -DOSG_PLUGIN_EXTENSION=.so -DUSE_ZLIB -DosgDB_EXPORTS -I/Users/janke/local/opp/openscenegraph/OpenSceneGraph/include -I/Users/janke/local/opp/openscenegraph/OpenSceneGraph/build/include  -std=c++11 -stdlib=libc++  -Wno-conversion -O3 -DNDEBUG -fPIC   -x objective-c++ -o CMakeFiles/osgDB.dir/FileUtils.cpp.o -c /Users/janke/local/opp/openscenegraph/OpenSceneGraph/src/osgDB/FileUtils.cpp

Differences I can see:

• It's calling c++ (Apple Clang) directly, instead of Homebrew's superenv clang++ wrapper.
• It's not passing -F/Applications/Xcode-7.1.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/Frameworks to explicitly specify a framework search path.
• Not passing -isysroot /Applications/Xcode-7.1.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk
• Not passing -arch x86_64 or -x objective-c++
• Passing -O3 -DNDEBUG

I wonder if something about that -F or -isysroot is making a difference. Maybe outside of Homebrew, it's identifying the same diagnostic, but ignoring it since it's considering that Security.framework to be a system library, but it's not considering it a system library in the Homebrew build case.

[mkrapp]

You can add CFLAGS to the argument lists:

args << "-DCMAKE_CXX_FLAGS='-Wno-c++11-narrowing'"

[UniqMartin]

Since it's failing because of an error (a warning wouldn't cause the build to fail), you will have to disable this error by passing -Wno-error=narrowing in C++11 mode. However, this is prone to mask other issues and is not really what I am recommending.

The real problem is that Apple's headers are not C++11 clean and that they are working around this issue by disabling (for system headers) in their compiler what is in fact an actual error (see also this). I think because superenv decides to strip the -isysroot, the header is no longer recognized as a system header and Apple's failure to provide a correct header gets exposed. (I'm not entirely sure whether superenv or the formula's build system is to blame here, aside from Apple.)

[apjanke]

Doing the "-DCMAKE_CXX_FLAGS='-Wno-c++11-narrowing'" is enough to get it to compile on 10.11. (#46385). But getting it to ignore errors & warnings in the system headers sounds like a better approach.

(This particular error isn't a syntax error or some other hard failure; I think it's a clang diagnostic with a default severity level of "error", so the -Wno-c++11-narrowing can turn this diagnostic off entirely. The -Wno-error=narrowing would (I think) change the severity from an error to a warning, but Homebrew prefers to suppress warnings entirely, to avoid confusing end users. For example, superenv adding -w.)

Looking at the source for superenv, it looks like we emit the -isysroot flag only for non-CLT-installed systems, since extend/ENV/super.rb only sets effective_sysroot for non-CLT. (From there, HOMEBREW_SDKROOT gets set to effective_sysroot, and then the ENV cc wrapper initializes sysroot from HOMEBREW_SDKROOT.)

  def effective_sysroot
    MacOS::Xcode.without_clt? ? MacOS.sdk_path.to_s : nil
  end

Maybe we need to emit it for systems with CLT installed in some cases, either auto-detecting those cases (e.g. when compiling in C++11 mode), or adding an ENV method to allow formulae to request it be done? Having it set the effective sysroot unconditionally like the following got the build failure to go away, which seems to confirm that -isysroot will make it be seen as a system header and suppress those diagnostics automatically.

  def effective_sysroot
    MacOS.sdk_path.to_s
  end

I don't know either if if it's something specific about this formula (like whatever's causing that -F) that's causing those to not be treated as system headers, or if the way we're doing things means they're never seen as system headers, but we usually get away with that and the error is only cropping up under the new circumstances of building C++11 code against the 10.11 El Cap SDK which introduced non-C++11-clean headers.

[UniqMartin]

Thanks for the detailed analysis! I didn't realize at the time of writing that -Wno-c++11-narrowing would be sufficient, but of course it is.

As for the C++11 and SDK issue: There's not much to be added to your assessment, except:

• I think it is a partial failure in superenv on our side, as we do remove the -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk, but then fail to notice the -F/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/Frameworks and to make it consistent with the other adjustment by stripping it down to -F/System/Library/Frameworks (which then would be useless, as that is a default location).
• It is also partially a failure of OSG's build system that it is actually emitting this path with the -F option. (It shouldn't be necessary if my understanding of -isysroot is correct.)
• Well … and then there's Apple with its broken headers. Otherwise we probably wouldn't have noticed.

Not sure what the best attack vector for this issue is …