Project

General

Profile

Bug #1468

boost/assert.hpp:102:47: error: ‘noinline’ was not declared in this scope

Added by Christoph Junghans over 6 years ago. Updated about 6 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
build system
Target version:
Affected version - extra info:
Affected version:
Difficulty:
uncategorized
Close

Description

/usr/include/boost/assert.hpp:102:47: error: ‘noinline’ was not declared in
this scope
BOOST_NOINLINE void assertion_failed_msg(CharT const * expr, char
const * msg, char const * function,

Details:
<https://bugs.gentoo.org/show_bug.cgi?id=505480>


Related issues

Related to GROMACS - Bug #1402: Error compiling 5.0-beta1 with CUDA and gcc >= 4.6Closed12/11/2013

History

#1 Updated by Mark Abraham over 6 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 over 6 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.

#3 Updated by Mark Abraham over 6 years ago

gmx_fatal.h is being #included, but I can see no reason for that to end up #including assert.hpp.

#4 Updated by Teemu Murtola over 6 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 legacyheaders/smalloc.h -> utility/common.h.

#5 Updated by Roland Schulz over 6 years ago

https://gerrit.gromacs.org/#/c/3306/ probably works around the problem which isn't a Gromacs problem. I suggest closing the issue.

#6 Updated by Roland Schulz over 6 years ago

  • Status changed from Blocked, need info to Closed

#7 Updated by Teemu Murtola about 6 years ago

  • Related to Bug #1402: Error compiling 5.0-beta1 with CUDA and gcc >= 4.6 added

#8 Updated by Teemu Murtola about 6 years ago

  • Assignee changed from Mark Abraham to Teemu Murtola
  • Target version changed from 5.x to 5.0

Also available in: Atom PDF