boost/assert.hpp:102:47: error: ‘noinline’ was not declared in this scope
/usr/include/boost/assert.hpp:102:47: error: ‘noinline’ was not declared in
BOOST_NOINLINE void assertion_failed_msg(CharT const * expr, char
const * msg, char const * function,
#1 Updated by Mark Abraham almost 7 years ago
- Status changed from New to Blocked, need info
There's no GROMACS file I can see that even #includes assert.hpp, and the failing command is pretty opaque. Thus it is probably originating in something generated by CUDA. The build is picking up a system Boost 1.55. I've no idea what version of Boost may or may not be compatible with what CUDA, but setting
cmake -DGMX_EXTERNAL_BOOST=off should work around it. Whether that is good for any upstream library linking to GROMACS is another problem.
So far, I don't see a GROMACS problem to fix.
#2 Updated by Roland Schulz almost 7 years ago
Did you check whether this is still an issue with latest master. It might be fixed because the propagation of compiler flags to nvcc has been improved and this in turn might fix it. If not we could fix it by making sure we don't indirectly include boost from cuda code. Because we shoundn't need to.
#4 Updated by Teemu Murtola almost 7 years ago
Roland Schulz wrote:
If not we could fix it by making sure we don't indirectly include boost from cuda code. Because we shoundn't need to.
In principle, yes. But that may just create other problems for us in the future (this was also briefly discussed in #1402), unless we think that C++ code will never propagate deeper than it currently does. We just got rid of the insanity that CUDA code couldn't call any function declared in a header that declared a function that took a
t_commrec argument (duplicate functionality that this has prompted in CUDA code should still be removed, though); this would just create a similar mess, except that it would be even more difficult to split headers sensibly. Would we, for example, implement a separate exception hierarchy for CUDA that doesn't depend on boost::exception? If we need to do this, we should make Jenkins fail if someone violates the constraint. And should we make Jenkins fail artificially, even if we can't find a compiler/CUDA/boost combination that would trigger the error?
boost is currently propagating to CUDA likely from