Issues compiling ASPECT on stampede

[naliboff]

This issue follows a discussion in pull request #562 and is also directly related to issue #1260 and pull request #1263.

On stampede, I compiled Trilinos and dealii using the update instructions in #562. dealii step-32 runs successfully. Details of my dealii configuration (development branch, last updated commit on Nov 8) are in the attached detailed.log file.

However, an up to date development version of ASPECT (includes #1263 fix) is not able to build due to an error that is related to the 'emplace_hint' issue outlined in #1260.

For example, the last error message is: /work/01038/jboff/Software/dealii/dealii/include/deal.II/bundled/boost/serialization/map.hpp:65:51: error: ‘class std::map<std::basic_string, std::basic_string >’ has no member named ‘emplace_hint’

The full 'make' output results are also included in a file below.

Hopefully I'm just overlooking a simple fix or mistake in the configuration settings.

detailed.log.txt

aspect_compile_error.txt

[bangerth]

The interesting part of this code is this (from bundled/boost-.../include/boost/serialization.map.h)

        typename Container::iterator result =
            #ifdef BOOST_NO_CXX11_HDR_UNORDERED_MAP
                s.insert(hint, t.reference());
            #else
                s.emplace_hint(hint, t.reference());
            #endif

The interesting question is why BOOST_NO_CXX11_HDR_UNORDERED_MAP is not set.

Because you are compiling with GCC 4.7.1, this block in boost/config/stdlib/libstdcpp3.hpp should trigger:

//  C++0x headers in GCC 4.3.0 and later
//
#if (BOOST_LIBSTDCXX_VERSION < 40300) || !defined(BOOST_LIBSTDCXX11)
#  define BOOST_NO_CXX11_HDR_ARRAY
#  define BOOST_NO_CXX11_HDR_TUPLE
#  define BOOST_NO_CXX11_HDR_UNORDERED_MAP
#  define BOOST_NO_CXX11_HDR_UNORDERED_SET
#  define BOOST_NO_CXX11_HDR_FUNCTIONAL
#endif

In other words, BOOST believes that everything more recent than GCC 4.3 has the appropriate functionality. What is interesting is that the writers of serialization/map.h ask whether there are unordered maps when what they really should be asking whether emplace_hint is available. They may have gotten this part wrong. Can you check whether the map.h header of the compiler does/does not have this function?

[naliboff]

The compiler does indeed include references to emplace_hint in the files include/c++/4.7.1/profile/unordered_map, include/c++/4.7.1/profile/unordered_set, equivalent files in /include/debug and include/c++/4.7.1/bits/hashtable.h:.

There are no references to emplace_hint in any of the compiler map.h files (include/isl/map.h, 'include/c++/4.7.1/profile/map.h', include/c++/4.7.1/debug/map.h), though.

Would it help to see the details of the emplace_hint function in either unordered_map or unordered_set?

[bangerth]

For me, the emplace_hint function compiler uses is in include/c++/4.8.4/bits/stl_map.h. Can you check that it really isn't there?

If that's not the case: I guess that means that the BOOST check is wrong :-( What a disaster! I suspect that the best way to approach this may be to pass BOOST_NO_CXX11_HDR_UNORDERED_MAP on the compile line then, but this probably needs to be done in deal.II, not from ASPECT.

[naliboff]

Unfortunately /opt/apps/gcc/4.7.1/include/c++/4.7.1/bits/stl_map.h does not have emplace_hint. Within /opt/apps/gcc/4.7.1/include/c++/4.7.1/bits/, it is only located in hashtable.h.

I'll try recompiling with the modification to the deal.ii configuration. Is the exact addition something like -DBOOST_NO_CXX11_HDR_UNORDERED_MAP=ON?

[bangerth]

No, you need to do something like

  export CXXFLAGS=-DBOOST_NO_CXX11_HDR_UNORDERED_MAP

before calling deal.II's cmake. You probably want to start with a clean build directory. This should set the flag for each compile job.

Alternatively, I believe it should work if you did make clean, then used ccmake to edit the appropriate variables that pass compiler flags. But I've never done that, so I don't know how to exactly.

[naliboff]

Success compiling ASPECT, export CXXFLAGS=-DBOOST_NO_CXX11_HDR_UNORDERED_MAP did the trick. Thanks!

Should I open an issue on the deal.II page to report the bug?

I've also asked the Stampede folks if they can link gcc 4.9.1 with the MKL 13 libraries, which would an additional short-term workaround.

[bangerth]

Yes, please open a deal.II issue, with a link to here. Ideally, we would have a tiny test program that doesn't compile without the given -D... flag, but does when given. I don't know whether that's too complicated to construct, though.

[bangerth]

I reported this to the good folks at BOOST here: https://svn.boost.org/trac/boost/ticket/12755

[bangerth]

I double checked that this is also an issue with boost 1.63 (the current release).

[bangerth]

@naliboff -- is this fixed? Can we close the issue?

[gassmoeller]

@naliboff any news on the installation on stampede? Is this issue closed?

[naliboff]

@bangerth, @gassmoeller - sorry, missed this message on April 25. Yes, ok to close this issue as stampede1 is no longer in service and Harsha has successfully compiled on Stampede2. If there are issues with the scaling tests and compiler options on Stampede2 we can start a new conversation.

[gassmoeller]

No harm done. Closed.