Fwd: [stan-users] Re: Error trying to install rstan

60 views
Skip to first unread message

Ben Goodrich

unread,
Jul 24, 2015, 11:34:54 AM7/24/15
to stan...@googlegroups.com, avraha...@gmail.com
On Friday, July 24, 2015 at 11:11:34 AM UTC-4, Ben Goodrich wrote:
On Wednesday, July 22, 2015 at 5:11:51 PM UTC-4, Ben Goodrich wrote:
On Wednesday, July 22, 2015 at 5:08:13 PM UTC-4, Avraham Adler wrote:
Any ideas why -std=gnu++0x would cause the crash it did?

No, but it is also happening to me on Linux and presumably will happen once Daniel gets a chance to try on our Windows test machine. So, we can try to come up with a work around for the next StanHeaders / rstan.

Upon further review, -std=gnu++0x does not currently work with any interface to Stan if g++-4.6 is the compiler.

I can get it to work with the following patch that comments out some non-compiling stuff but does anyone see a better way?

goodrich@T540p:/opt/stan$ git diff lib/boost_1.58.0/ | cat
diff --git a/lib/boost_1.58.0/boost/fusion/support/unused.hpp b/lib/boost_1.58.0/boost/fusion/support/unused.hpp
index
4bbe24e..08dd9ed 100644
--- a/lib/boost_1.58.0/boost/fusion/support/unused.hpp
+++ b/lib/boost_1.58.0/boost/fusion/support/unused.hpp
@@ -48,14 +48,14 @@ namespace boost { namespace fusion
         
{
             
return *this;
         
}
-
+/*
         BOOST_CONSTEXPR BOOST_FUSION_GPU_ENABLED
         unused_type const&
         operator=(unused_type const&) const BOOST_NOEXCEPT
         {
             return *this;
         }
-
+*/

         BOOST_CXX14_CONSTEXPR BOOST_FUSION_GPU_ENABLED
         unused_type
&
         
operator=(unused_type const&) BOOST_NOEXCEPT
@@ -64,7 +64,7 @@ namespace boost { namespace fusion
         
}
     
};
 
-    BOOST_CONSTEXPR unused_type const unused = unused_type();
+    BOOST_CONSTEXPR unused_type /*const*/ unused = unused_type();
 
     
namespace detail
     
{

Ben

Bob Carpenter

unread,
Jul 24, 2015, 1:35:48 PM7/24/15
to stan...@googlegroups.com, avraha...@gmail.com
This looks like it's related to some known issues with
the Intel compiler, where they can't handle the const version of
this operation.

I'm coming to the conclusion that Boost's too tricky for it's own
good. I'd really like to remove our dependency on their
compiler (which depends on all this lazy evaluation stuff that's
always causing problems cross-compiler). But that's a huge
project --- it touches the entire parser and abstract syntax
tree generation.

- Bob
> --
> You received this message because you are subscribed to the Google Groups "stan development mailing list" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to stan-dev+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Ben Goodrich

unread,
Jul 24, 2015, 1:43:49 PM7/24/15
to stan development mailing list, ca...@alias-i.com, avraha...@gmail.com, ca...@alias-i.com
On Friday, July 24, 2015 at 1:35:48 PM UTC-4, Bob Carpenter wrote:
This looks like it's related to some known issues with
the Intel compiler, where they can't handle the const version of
this operation.  

But this is g++, albeit mostly pre-C++11

BTW: Here is the error

goodrich@T540p:/opt/stan/lib/stan_math_2.7.0$ make stan/math/prim/arr/functor/integrate_ode.hpp-test
g++-4.6 -std=gnu++0x -I . -isystem ../../lib/eigen_3.2.4 -isystem ../../lib/boost_1.58.0 -Wall -DBOOST_RESULT_OF_USE_TR1 -DBOOST_NO_DECLTYPE -DBOOST_DISABLE_ASSERTS -pipe   -c -O0 -include sta
n
/math/prim/arr/functor/integrate_ode.hpp -o /dev/null test/dummy.cpp
In file included from ../../lib/boost_1.58.0/boost/fusion/view/zip_view/zip_view.hpp:13:0,
                 
from ../../lib/boost_1.58.0/boost/fusion/view/zip_view.hpp:12,
                 
from ../../lib/boost_1.58.0/boost/fusion/include/zip_view.hpp:11,
                 
from ../../lib/boost_1.58.0/boost/numeric/odeint/util/resize.hpp:26,
                 
from ../../lib/boost_1.58.0/boost/numeric/odeint/util/state_wrapper.hpp:26,
                 
from ../../lib/boost_1.58.0/boost/numeric/odeint/util/ublas_wrapper.hpp:33,
                 
from ../../lib/boost_1.58.0/boost/numeric/odeint.hpp:25,
                 
from ./stan/math/prim/arr/functor/integrate_ode.hpp:12,
                 
from <command-line>:0:
../../lib/boost_1.58.0/boost/fusion/support/unused.hpp: In member function const boost::fusion::unused_type& boost::fusion::unused_type::operator=(const boost::fusion::unused_type&) const’:
../../lib/boost_1.58.0/boost/fusion/support/unused.hpp:57:9: error: this is not a potential constant expression
../../lib/boost_1.58.0/boost/fusion/support/unused.hpp: At global scope:
../../lib/boost_1.58.0/boost/fusion/support/unused.hpp:67:39: error: both const and constexpr cannot be used here
make
/tests:64: recipe for target 'stan/math/prim/arr/functor/integrate_ode.hpp-test' failed
make
: *** [stan/math/prim/arr/functor/integrate_ode.hpp-test] Error 1


Bob Carpenter

unread,
Jul 24, 2015, 1:52:14 PM7/24/15
to stan...@googlegroups.com
Sebastian was telling us that the Intel compilers were related
to g++. But whatever the cause, I was just pointing out it's
the same kind of const declaration that we had to fix for
Intel.

- Bob

Ben Goodrich

unread,
Jul 24, 2015, 1:58:40 PM7/24/15
to stan development mailing list, ca...@alias-i.com, ca...@alias-i.com
On Friday, July 24, 2015 at 1:52:14 PM UTC-4, Bob Carpenter wrote:
Sebastian was telling us that the Intel compilers were related
to g++.   But whatever the cause, I was just pointing out it's
the same kind of const declaration that we had to fix for
Intel.

OK. What did we do to fix it? This should go into BH because another R package has the same build error

https://www.r-project.org/nosvn/R.check/r-release-windows-ix86+x86_64/odeintr-00install.html

Ben

Sebastian Weber

unread,
Jul 26, 2015, 5:30:40 AM7/26/15
to stan development mailing list
Hi

To clarify: the intel compiler aims to produce g++ comparible binaier so that you can mix libraries compiled with either compiler. Second, you can use the intel mkl together with g++. The intel mkl provides high speed versions of linear algebra operations optimized for intel processors - it can even lay off computations on intels graphics card type processors fully automatically, this is why eigen can be compiled in mkl mode, then they switch to these operations.

Concerning the issue with the const operator and intel 14: the solution was to disable this for the intel compiler which meant to ifdef this stuff out of the boost headers and in addition bob programmed around it. Just have a look at the not-in-bh extra includes which you have in rstan to override the original boost bh includes.

Hope that helps.
Sebastian

Sebastian Weber

unread,
Jul 26, 2015, 5:34:44 AM7/26/15
to stan development mailing list
@ben: if you want fast odes in r, then have a look at the cOde package. It translates your ode system into a c function for you and then you can use desolve on it and get a fast lsoda solver. Really neat for easy ans fast simulations in r. Not sure what the odeintr adds to this, but then i don't know that package at all.

... Code you even get the jacobian and hessian...

Ben Goodrich

unread,
Jul 27, 2015, 1:08:15 AM7/27/15
to stan development mailing list, sdw....@gmail.com, sdw....@gmail.com
On Sunday, July 26, 2015 at 5:30:40 AM UTC-4, Sebastian Weber wrote:
Concerning the issue with the const operator and intel 14: the solution was to disable this for the intel compiler which meant to ifdef this stuff out of the boost headers and in addition bob programmed around it. Just have a look at the not-in-bh extra includes which you have in rstan to override the original boost bh includes.

I think it is simpler in this case:
BOOST_CONSTEXPR unused_type const unused = unused_type();

in boost/fusion/support/unused.hpp then it looks like you don't even need the last two specializations that cause g++-4.6 to not compile

   struct unused_type
   {
       BOOST_CONSTEXPR BOOST_FUSION_GPU_ENABLED
       unused_type() BOOST_NOEXCEPT
       {
       }

       template <typename T>
       BOOST_CONSTEXPR BOOST_FUSION_GPU_ENABLED
       unused_type(T const&) BOOST_NOEXCEPT
       {
       }

       template <typename T>
       BOOST_CONSTEXPR BOOST_FUSION_GPU_ENABLED
       unused_type const&
       operator=(T const&) const BOOST_NOEXCEPT
       {
           return *this;
       }

       template <typename T>
       BOOST_CXX14_CONSTEXPR BOOST_FUSION_GPU_ENABLED
       unused_type&
       operator=(T const&) BOOST_NOEXCEPT
       {
           return *this;
       }  

       BOOST_CONSTEXPR BOOST_FUSION_GPU_ENABLED
       unused_type const&
       operator=(unused_type const&) const BOOST_NOEXCEPT                                        
       {
           return *this;
       }

       BOOST_CXX14_CONSTEXPR BOOST_FUSION_GPU_ENABLED
       unused_type&
       operator=(unused_type const&) BOOST_NOEXCEPT
       {
           return *this;
       }
   };

Ben

Avraham Adler

unread,
Jul 27, 2015, 10:59:55 AM7/27/15
to stan development mailing list, sdw....@gmail.com, goodri...@gmail.com
On Monday, July 27, 2015 at 1:08:15 AM UTC-4, Ben Goodrich wrote:
> I think it is simpler in this case:
> G++ 4.7.x just stopped considering this construction to be invalid ( https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54086 ) but didn't backport the fix to 4.6.x

As Rtools development for 4.9.x is all but stopped (Kevin Ushey has someone working on it, but it's not anywhere near completion last I checked), those of us who use R/Stan/rstan on windows would appreciate any fixes. For the time being, as long as Makevars doesn't pass -gnu++0x or -c++0x, it will work, so it should be lower priority than true bugs, IMHO.

Thanks!

Avi

Ben Goodrich

unread,
Jul 27, 2015, 11:08:03 AM7/27/15
to stan development mailing list, avraha...@gmail.com, avraha...@gmail.com

It should work for you with C++11 if you modify your local BH/include/boost/fusion/support/unused.hpp along the lines of my previous post. It seems to be a Boost issue rather than a Stan issue, but I doubt it is a high priority issue for Boost either.

Ben


Reply all
Reply to author
Forward
0 new messages