Configure fails to compile eigen_test on OS X 10.8 using clang++ version 4.2

[calewis]

While trying to configure Tiledarray on OS X 10.8 using clang++ the configure step fails while trying to compile the eigen example. The compile command is the following

/opt/mpich2/bin/mpicxx -std=c++11 -DEIGEN_COMPILES -I/usr/local/include/eigen3 -o CMakeFiles/ cmTryCompileExec2548984095.dir/src.cxx.o -c /Users/drewlewis/software/build/tiledarray/tiledarray/CMakeFiles/CMakeTmp/src.cxx

The error is

In file included from /Users/drewlewis/software/build/tiledarray/tiledarray/CMakeFiles/CMakeTmp/src.cxx:2:
9 In file included from /usr/local/include/eigen3/Eigen/Core:256:
10 /usr/local/include/eigen3/Eigen/src/Core/util/Memory.h:737:23: error: no member named 'forward' in namespace 'std'
11 ::new(p) T(std::forward(args)...);

Suspected solution is that when compiling with clang++ CXXFLAGS should include -stdlib=libc++

[asadchev]

Correct. For compatability purposes, clang uses older stdlib which doesn't
have support for std::forward
On Aug 20, 2013 4:37 PM, "Drew Lewis" notifications@github.com wrote:

While trying to configure Tiledarray on OS X 10.8 using clang++ the
configure step fails while trying to compile the eigen example. The compile
command is the following

/opt/mpich2/bin/mpicxx -std=c++11 -DEIGEN_COMPILES
-I/usr/local/include/eigen3 -o CMakeFiles/
cmTryCompileExec2548984095.dir/src.cxx.o -c
/Users/drewlewis/software/build/tiledarray/tiledarray/CMakeFiles/CMakeTmp/src.cxx

The error is

In file included from
/Users/drewlewis/software/build/tiledarray/tiledarray/CMakeFiles/CMakeTmp/src.cxx:2:
9 In file included from /usr/local/include/eigen3/Eigen/Core:256:
10 /usr/local/include/eigen3/Eigen/src/Core/util/Memory.h:737:23: error:
no member named 'forward' in namespace 'std'
11 ::new(p) T(std::forward(args)...);

Suspected solution is that when compiling with clang++ CXXFLAGS should
include -stdlib=libc++

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1
.

[justusc]

The problem is a faulty test in the configure script, which is also in MPQC.

I have already pushed a fix to the repo.

On Aug 20, 2013, at 4:36 PM, Drew Lewis notifications@github.com wrote:

While trying to configure Tiledarray on OS X 10.8 using clang++ the configure step fails while trying to compile the eigen example. The compile command is the following

/opt/mpich2/bin/mpicxx -std=c++11 -DEIGEN_COMPILES -I/usr/local/include/eigen3 -o CMakeFiles/ cmTryCompileExec2548984095.dir/src.cxx.o -c /Users/drewlewis/software/build/tiledarray/tiledarray/CMakeFiles/CMakeTmp/src.cxx

The error is

In file included from /Users/drewlewis/software/build/tiledarray/tiledarray/CMakeFiles/CMakeTmp/src.cxx:2:
9 In file included from /usr/local/include/eigen3/Eigen/Core:256:
10 /usr/local/include/eigen3/Eigen/src/Core/util/Memory.h:737:23: error: no member named 'forward' in namespace 'std'
11 ::new(p) T(std::forward(args)...);

Suspected solution is that when compiling with clang++ CXXFLAGS should include -stdlib=libc++

—
Reply to this email directly or view it on GitHub.

[evaleev]

@justusc What was the issue in validating Eigen in cmake?

[justusc]

@evaleev

I do not remember the exact failure. The problem was that Eigen was failing the compile test, even though CMake was finding an appropriate Eigen installation. Drew's failure was different than my failure (something related to C++11), but the situation was the same.

I think I did not need his fix because I was using CXXFLAGS="-std=c++11 -stdlib=libc++," where Drew was using CXXFLAGS="-stdlib=libc++" and relying on the configure script to add "-std=c++11." So the configure script was using C++11 library with the C++98 (03?) headers. I think he avoided the issue in his change by only using parts of Eigen that does not rely on C++.

We should probably change the test to be more robust since his will likely be broken in future Eigen releases as they include more C++11 code.

Overall the problems seem to be introduced due to different versions on different computers.

[asadchev]

When you compile Eigen with c++11 it assumes you have full support for
rvalues, including std:.forward, which is in stdlib. However, the system
stdlib, which clang uses by default, has no support for forward. So if you
want that, you have to specifically tell clang to use its own stslib.
Hopefully that clears it
On Aug 21, 2013 10:30 AM, "Justus Calvin" notifications@github.com wrote:

@evaleev https://github.com/evaleev

I do not remember the exact failure. The problem was that Eigen was
failing the compile test, even though CMake was finding an appropriate
Eigen installation. Drew's failure was different than my failure (something
related to C++11), but the situation was the same.

I think I did not need his fix because I was using CXXFLAGS="-std=c++11
-stdlib=libc++," where Drew was using CXXFLAGS="-stdlib=libc++" and relying
on the configure script to add "-std=c++11." So the configure script was
using C++11 library with the C++98 (03?) headers. I think he avoided the
issue in his change by only using parts of Eigen that does not rely on C++.

We should probably change the test to be more robust since his will likely
be broken in future Eigen releases as they include more C++11 code.

Overall the problems seem to be introduced due to different versions on
different computers.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-23020700
.

[evaleev]

Yes, I noticed that there are subtle differences in clang behaving with and
without std=c++11. We should always add the c++11 explicitly.
On Aug 21, 2013 10:30 AM, "Justus Calvin" notifications@github.com wrote:

@evaleev https://github.com/evaleev

I do not remember the exact failure. The problem was that Eigen was
failing the compile test, even though CMake was finding an appropriate
Eigen installation. Drew's failure was different than my failure (something
related to C++11), but the situation was the same.

I think I did not need his fix because I was using CXXFLAGS="-std=c++11
-stdlib=libc++," where Drew was using CXXFLAGS="-stdlib=libc++" and relying
on the configure script to add "-std=c++11." So the configure script was
using C++11 library with the C++98 (03?) headers. I think he avoided the
issue in his change by only using parts of Eigen that does not rely on C++.

We should probably change the test to be more robust since his will likely
be broken in future Eigen releases as they include more C++11 code.

Overall the problems seem to be introduced due to different versions on
different computers.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-23020700
.

[calewis]

I changed the test already, not to necessarily use c++11 or to avoid it, but to actually be something that made sense.

The old code did the following
make random square matrix -> not likely to be symmetric.
symmetric eigensolve on random square matrix-> most of the time this will return a matrix of nan
compute the inverse square root of the random matrix -> once again nan because eigensolve didn't work.

new code makes a single change that makes the code make sense
make random square matrix = m
m = m.transpose() + m -> this is guaranteed to be symmetric so the rest of the code will work and return a real answer almost all the time unless our random matrix happens to be singular. This unlikely but possible for a random matrix.

I know that this was just a compile check and so the code being used doesn't matter all that much as long as it is valid Eigen code, but I think a pathological example is probably a bad choice to test whether or not Eigen compiles.

~Drew
On Aug 21, 2013, at 10:24 AM, Justus Calvin notifications@github.com wrote:

@evaleev

I do not remember the exact failure. The problem was that Eigen was failing the compile test, even though CMake was finding an appropriate Eigen installation. Drew's failure was different than my failure (something related to C++11), but the situation was the same.

I think I did not need his fix because I was using CXXFLAGS="-std=c++11 -stdlib=libc++," where Drew was using CXXFLAGS="-stdlib=libc++" and relying on the configure script to add "-std=c++11." So the configure script was using C++11 library with the C++98 (03?) headers. I think he avoided the issue in his change by only using parts of Eigen that does not rely on C++.

We should probably change the test to be more robust since his will likely be broken in future Eigen releases as they include more C++11 code.

Overall the problems seem to be introduced due to different versions on different computers.

—
Reply to this email directly or view it on GitHub.

[justusc]

@asadchev
You are correct and this is sensible behavior for Eigen. However, the issue is in how and when C++11 flags are being given to the compiler. TA is currently setup to add -std=c++11. So if a user relies on this mechanism to add the that flag, as Drew did, the test will fail on OS X if Eigen uses C++11 code. This is because, as you pointed out, two flags are required, but the script only checks one of these flags.

@evaleev
We have two options here:

1. Let the user specify the C++11 flags.
2. Let the configure script set the C++11 flags.

I am inclined to go with option 1 because it is too much work to try and keep up with all the options for different compilers, it simplifies the scripts, and there may be cases where the user does not or cannot use c++11. Also, TA and all its dependencies will work without C++11. Finally, I think it is better to use what is given by the user than to modify compile flags without reason.

[evaleev]

In general it makes sense to let user take the responsibility. In this case i think we should provide a general workaround, I.e. if compiler silently accepts c++11 code we should add c++11 flag. This makes manifestly clear what the compiler actually does. This way, if the user specifies explicitly std=c++03 the flag will be honored.

[justusc]

@evaleev Yes, but this is the situation that we are in right now, and it is prone to failure. In the current implementation we are responsible for providing C++11 flags, but it only works for GCC as far as I know. Other compilers, including clang, xlc, and Intel will all fail because they require other flags in addition to -std=c++11 to work properly.

On the other hand, if we completely ignore the C++11 flag issue and a compile test fails because C++11 flags are set incorrectly, then we make it the user's responsibility to provide proper C++11 flags.

Again, it does not make much sense to include them in TiledArray since it does not require C++11. MADNESS can use C++11 features, but it is optional and requires no user input to make it work correctly.

MPQC is a different story since it requires C++11 features. There we do need to do a better job of detecting compiler support for C++11 and provide good compiler flags.

[evaleev]

OK, sounds convincing. At least for TA and MADNESS.

[justusc]

Fixed