compile error in PetaverseMOSES

Bug #898243 reported by Thomas Dziedzic on 2011-11-30
This bug affects 4 people
Affects Status Importance Assigned to Milestone

Bug Description

I have attached the full error message,

here is a little snippet that I thought would probably be sort of relevant

/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.2/../../../../include/c++/4.6.2/thread:194:67: error: could not convert ‘boost::make_shared(Arg1&&, Args&& ...) [with T = std::thread::_Impl<std::_Bind_result<void, boost::_mfi::mf0<void, std::__future_base::_Async_state<std::pair<std::vector<const

using boost 1.47 on archlinux

Thomas Dziedzic (gostrc) wrote :
linas (linasvepstas) wrote :

built for me, with boost 1.46.1 and gcc-4.6.2 -- Since the compilers are the same, this must be a boost-1.47 problem...

Thomas Dziedzic (gostrc) wrote :

I just tried again, this time with boost 1.48.0 and it still failed.

I see the same error on gcc 4.5.3, boost 1.47

Actually, no, the error I see is on the same file, but two lines earlier. It's just an include in the end, so I assume it's a bug in boost 1.47

(I wish there was a way to edit/delete my comments)

No, back to the original assesment, I'm seeing the same error.

This line is the culprit (metapopulation.h, line 765, as of bzr trunk around today):

std::future<bscored_combo_tree_ptr_vec> task =
                std::async(jobs > 1 ? std::launch::async : std::launch::sync,
                           bind(&self::get_nondominated_rec, this,
                                bcv_p.first, s_jobs.first));

If I can read the error correctly, it's saying that the right hand side returns a boost::shared_ptr around the future construct, while the left hand side is a std::shared_ptr around the future construct. I don't understand how either shared_ptr makes it into the picture, but even less how the boost::shared_ptr pops up there.

linas (linasvepstas) wrote :

arghhh I am guessing that this is because of the use of boost::ptr_vector<BScore> for holding scores. ...

linas (linasvepstas) wrote :

Try this, let me know if it works:

=== modified file 'opencog/comboreduct/reduct/using.h'
--- opencog/comboreduct/reduct/using.h 2011-07-04 05:39:34 +0000
+++ opencog/comboreduct/reduct/using.h 2012-02-03 18:28:46 +0000
@@ -28,7 +28,6 @@
 //#include <boost/bind.hpp>
 #include <boost/iterator/counting_iterator.hpp>
 #include <boost/iterator/indirect_iterator.hpp>
-#include <boost/shared_ptr.hpp>
 #include <boost/ptr_container/ptr_vector.hpp>

 #include <opencog/comboreduct/combo/vertex.h>
@@ -46,11 +45,11 @@
 using boost::make_counting_iterator;
 using boost::make_indirect_iterator;
 using boost::apply_visitor;
-using boost::shared_ptr;
 using boost::ptr_vector;
 using std::find_if;
 using std::distance;
 using std::make_pair;
+using std::shared_ptr;

 } // ~namespace reduct

I'm testing this now, I don't yet know if it will work for me.

linas (linasvepstas) wrote :

Compiles and passes all tests for me, will push this as change 6557 (or later, after rebase)

Changed in opencog:
importance: Undecided → High

Sorry about the delay Linas, I didn't realise I wasn't subscribed to the ticket.

Patch makes no difference. I still get the same error (I get a different error from trunk, but that's probably a different problem).

linas (linasvepstas) wrote :

I've patched trunk with the above patch, long ago; we should focus on what's happening in trunk.

Ok, I'll create a new bug report. I'd leave this one open for now, though.

linas (linasvepstas) wrote :

I've recently built all of opencog with gcc-4.7.0 and boost 1.49 This did require some cleanup; perhaps this build break went away?

I can confirm this bug still appears in Arch (latest updates). However, the partial build seems functional (the error is on 97% with me) - CogServer, MOSES and other major components work fine. As far as I know, only the Python bindings don't work (because they also cause a build error under Arch).

I can also confirm that a full build on Ubuntu 11.10 happens without errors.

linas (linasvepstas) wrote :

I'm confused ... what filename is this failing on?

Holger Friedrich (holgerf) wrote :

appears still in trunk (rev6752) on Debian testing with gcc version 4.6.3 (Debian 4.6.3-1), boost 1.49 (libboost-all-dev, etc.).

linas (linasvepstas) wrote :

Nil, 4 different people seem to have hit this, can you figure out what's going on?

Changed in opencog:
status: New → Confirmed
linas (linasvepstas) on 2014-12-29
Changed in opencog:
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers