clang -std=cxx11 build failure

[David Evans]

Build of trunk fails when building with Apple clang -std=cxx11 on Mac OS X 10.7 (Lion), 10.8 (Mountain Lion), 10.9 (Mavericks) using the default Xcode version for each platform.

See <https://trac.macports.org/wiki/XcodeVersionInfo#OSX10.9> for compiler configurations.

Mode of failure:

extension/internal/grid.cpp:118:27: error: non-constant-expression cannot be narrowed from type 'double' to 'float' in initializer list [-Wc++11-narrowing]
    float spacings[2] = { scale*module->get_param_float("xspacing"),
                                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
extension/internal/grid.cpp:118:27: note: override this message by inserting an explicit cast
    float spacings[2] = { scale*module->get_param_float("xspacing"),
                                            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                          static_cast<float>( )
extension/internal/grid.cpp:119:27: error: non-constant-expression cannot be narrowed from type 'double' to 'float' in initializer list [-Wc++11-narrowing]
                          scale*module->get_param_float("yspacing") };
                          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
extension/internal/grid.cpp:119:27: note: override this message by inserting an explicit cast
                          scale*module->get_param_float("yspacing") };
                          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                          static_cast<float>( )
extension/internal/grid.cpp:121:26: error: non-constant-expression cannot be narrowed from type 'double' to 'float' in initializer list [-Wc++11-narrowing]
    float offsets[2] = { scale*module->get_param_float("xoffset"),
                                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
extension/internal/grid.cpp:121:26: note: override this message by inserting an explicit cast
    float offsets[2] = { scale*module->get_param_float("xoffset"),
                                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                         static_cast<float>( )
extension/internal/grid.cpp:122:26: error: non-constant-expression cannot be narrowed from type 'double' to 'float' in initializer list [-Wc++11-narrowing]
                         scale*module->get_param_float("yoffset") };
                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
extension/internal/grid.cpp:122:26: note: override this message by inserting an explicit cast
                         scale*module->get_param_float("yoffset") };
                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                         static_cast<float>( )
4 errors generated.
make[3]: *** [extension/internal/grid.o] Error 1

As the error messages say using a double expression as an initializer for a float variable is not allowed in C++11 without
an explicit cast. The attached patch solves the problem and is currently being used with success on MacPorts.

This bug can be demonstrated with current inkscape trunk (r13158) but was introduced in r13018.

[su_v (suv-lp)]

Patched trunk (r13156) builds ok on OS X 10.7.5 with
- regular builds (i.e. not using C++11) with llvm-gcc-4.2 and clang 3.1 (Xcode 4.3.2)
- experimental build configured with '-std=c++11 -stdlib=libstdc++' with clang 3.1 (requires the patch)

[David Evans (devans-n)]

I should mention the current configurations that the MacPorts build bots are using (all build successfully, those using -std=c++11 fail without the patch) :

OS X 10.6
Xcode 4.2 (Build 4C199)
llvm-gcc: i686-apple-darwin10-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00) without any '-std=c++11'

OS X 10.7
Xcode 4.6.3 (build 4H1503)
Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn) '-std=c++11 -stdlib=libstdc++'

OS X 10.8
Xcode 5.0.2 (build 5A3005)
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) '-std=c++11 -stdlib=libstdc++'

OS X 10.9
Xcode 5.0.2 (build 5A3005)
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) '-std=c++11 -stdlib=libc++'

In addition, I, personally, have successfully built (with the patch, fails without) on

OS X 10.8
Xcode 5.1 (build 5B130a )
Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn) '-std=c++11 -stdlib=libstdc++'

OS X 10.9
Xcode 5.1 (build 5B130a )
Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn) '-std=c++11 -stdlib=libc++'

I note also that this patch does not introduce any new C++11 only features, just makes the code compatible with
with the C++11 standard (as interpreted by clang).

[su_v (suv-lp)]

Attaching build log with error of unpatched trunk (r13158) on OS X 10.7.5 (clang with '-std=c++11') as plain text (same error as in the bug description).

[su_v (suv-lp)]

AFAIU enforcing c++11 with current trunk is only necessary if compiling with libc++ (instead of libstdc++), i.e. on Mavericks.

It certainly is not needed on Lion, and will fail on that platform with more advanced C++11 features anyway (e.g. the compile time checking mentioned in this thread: <http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/42740>).

[David Evans (devans-n)]

Yes, I'll take a look at that. But the point here is that the patch is necessary if c++11 is required (on Mavericks at least) and doesn't hurt if it isn't.

[su_v (suv-lp)]

Attaching related warnings (no build failure) of inkscape-trunk from Ubuntu 13.10 buildbot (GCC 4.8.2):
<https://launchpad.net/~inkscape.dev/+archive/trunk/+build/5817501>

Patched trunk r13158 builds ok (without these warnings) on Ubuntu 13.10 (VM, 64bit).

@JazzyNico - any chance you could test the patch on Windows?

[jazzynico (jazzynico)]

> @JazzyNico - any chance you could test the patch on Windows?

Done, no build error or warning (regular build, c++11 not enforced).

[Jon A. Cruz (jon-joncruz)]

The patch suppresses the fatal warnings by casting... but a proper fix is probably to use consistent datatypes to begin with.

[David Evans (devans-n)]

I agree. The datatype cleanup in r13163 solves the problem in a much cleaner way. Thanks for your prompt attention to this bug.

[David Evans (devans-n)]

Confirming that after r13163 all MacPorts configurations listed above build successfully without any need for the attached patch.

[su_v (suv-lp)]

Fix committed in r13163.