[tr1][functional] fails to compile under gcc 4.0.1 on OS X
This code compiles using Intel ICC 10.1, but fails with "error: utility: No such file or directory in file included from /usr/local/ include/boost/tr1/functional.hpp" under gcc : #include <boost/tr1/functional.hpp> namespace mcs { class SPGR { public: SPGR(double TR,double TE,double alpha,double T10,double T20,double r1,double r2) { } ~SPGR() { } double Xi(double C) const { return 1.0; } void test() const; }; inline void SPGR::test() const { using namespace std::tr1::placeholders; std::tr1::function<double (double)> f(std::tr1::bind(&SPGR::Xi,this,_1)); } } // namespace mcs int main() { mcs::SPGR spgr(10,1,15,1000,100,4e-3,5e-3); return 0; } I don't think I'm doing anything blatantly stupid here...any ideas on what's going on? Matthias
Matthias Schabel wrote:
This code compiles using Intel ICC 10.1, but fails with "error: utility: No such file or directory in file included from /usr/local/ include/boost/tr1/functional.hpp" under gcc :
I don't think I'm doing anything blatantly stupid here...any ideas on what's going on?
Is this with Boost-1.34 ? If so there is a known bug (fixed in the Trunk, and hense the next release), which strikes only if Boost-1.34 is installed into an include path that appears *before* the gcc std lib include path. Typically this happens if Boost is installed into /usr/include by your Linux distro. The only workaround if you want to stick with 1.34, is to place the 1.34 headers in a directory that isn't normally part of your include path, and then add an explicit -I option to your command line so the headers are found. HTH, John.
This code compiles using Intel ICC 10.1, but fails with "error: utility: No such file or directory in file included from /usr/local/ include/boost/tr1/functional.hpp" under gcc :
I don't think I'm doing anything blatantly stupid here...any ideas on what's going on?
Is this with Boost-1.34 ? If so there is a known bug (fixed in the Trunk, and hense the next release), which strikes only if Boost-1.34 is installed into an include path that appears *before* the gcc std lib include path. Typically this happens if Boost is installed into /usr/include by your Linux distro.
Unfortunately not. I'm using a fairly recent snapshot of the trunk; version.hpp gives 103500. Boost is installed in the default location : /usr/local/include/boost-1_35, with a symlink to it in /usr/ local/include/boost... I'll try checking out the latest trunk if you think that will help... I'm compiling on OS X 10.5.1, BTW. Matthias
Unfortunately not. I'm using a fairly recent snapshot of the trunk; version.hpp gives 103500. Boost is installed in the default location : /usr/local/include/boost-1_35, with a symlink to it in / usr/ local/include/boost... I'll try checking out the latest trunk if you think that will help... I'm compiling on OS X 10.5.1, BTW.
Matthias
Interestingly, if I change the #include to #include <tr1/functional> the code compiles under gcc but fails under icc with the following error : /usr/include/c++/4.0.0/tr1/bind_iterate.h(45): error: expression must have (pointer-to-) function type { return _M_f(_GLIBCXX_BIND_V_ARGS); } ^ detected during: instantiation of "std::tr1::result_of<_Functor (std::tr1::result_of<std::tr1::_Mu<_T1, std::tr1::is_bind_expression<_T1>::value, <expression>> (_T1, std::tr1::tuple<_U1, std::tr1::_NullClass, std::tr1::_NullClass, std::tr1::_NullClass, std::tr1::_NullClass, std::tr1::_NullClass, std::tr1::_NullClass, std::tr1::_NullClass, std::tr1::_NullClass, std::tr1::_NullClass>)>::type, std::tr1::result_of<std::tr1::_Mu<_T2, std::tr1::is_bind_expression<_T2>::value, <expression>> (_T2, std::tr1::tuple<_U1, std::tr1::_NullClass, std::tr1::_NullClass, std::tr1::_NullClass, std::tr1::_NullClass, std::tr1::_NullClass, std::tr1::_NullClass, std::tr1::_NullClass, std::tr1::_NullClass, std::tr1::_NullClass>)>::type)>::type std::tr1::_Bind<_Functor (_T1, _T2)>::operator()(_U1 &) [with _Functor=double (mcs::SPGR::*)(double) const, _T1=const mcs::SPGR *, _T2=std::tr1::_Placeholder<1>, _U1=double]" at line 488 of "/usr/ include/c++/4.0.0/tr1/functional_iterate.h" instantiation of "_Res std::tr1::_Function_handler<_Res (_T1), _Functor>::_M_invoke(const std::tr1::_Any_data &, _T1) [with _Res=double, _Functor=std::tr1::_Bind<double (mcs::SPGR::*(const mcs::SPGR *, std::tr1::_Placeholder<1>))(double) const>, _T1=double]" at line 850 of "/usr/include/c++/4.0.0/tr1/functional_iterate.h" instantiation of "std::tr1::function<_Res (_T1)>::function(_Functor, std::__enable_if<std::tr1::function<_Res (_T1)>::_Useless, <expression>>::__type) [with _Res=double, _T1=double, _Functor=std::tr1::_Bind<double (mcs::SPGR::*(const mcs::SPGR *, std::tr1::_Placeholder<1>))(double) const>]" at line 32 of "/Volumes/matthias.schabel/Code/main/test_icc_tr1_bind.cpp" compilation aborted for /Volumes/matthias.schabel/Code/main/ test_icc_tr1_bind.cpp (code 2) Matthias
Matthias Schabel wrote:
This code compiles using Intel ICC 10.1, but fails with "error: utility: No such file or directory in file included from /usr/local/ include/boost/tr1/functional.hpp" under gcc :
I don't think I'm doing anything blatantly stupid here...any ideas on what's going on?
Is this with Boost-1.34 ? If so there is a known bug (fixed in the Trunk, and hense the next release), which strikes only if Boost-1.34 is installed into an include path that appears *before* the gcc std lib include path. Typically this happens if Boost is installed into /usr/include by your Linux distro.
Unfortunately not. I'm using a fairly recent snapshot of the trunk; version.hpp gives 103500. Boost is installed in the default location : /usr/local/include/boost-1_35, with a symlink to it in /usr/ local/include/boost... I'll try checking out the latest trunk if you think that will help... I'm compiling on OS X 10.5.1, BTW.
The change to the gcc configuration was made in changeset 39408 on 2007/20/09, and since I don't have access to Darwin this could be painful to track down (it's pretty painful when you *do* have access to the platform in question!) Can you let me have a full listing of the result of building with: g++ -v, then *maybe* I can see what the issue is. Thanks, John.
participants (2)
-
John Maddock -
Matthias Schabel