build fails about moses HOT 12 CLOSED

I think that's related to #27.
I couldn't reproduce it (even after cleaning the project) in my computer,
but two persons with similar errors couldn't be a coincidence.
So I tested in a new ubuntu 15.10 VM and I got exactly this error.
I don't know the difference between the two that causes it, I'll try to
find it later and post here.

On Mon, Nov 30, 2015 at 11:32 PM, chris hawley [email protected]
wrote:

Linking CXX executable combo-fmt-converter
../libcomboreduct.so: undefined reference to
`opencog::combo::operator>>(std::istream&, opencog::tree, std::allocator >,
opencog::combo::indefinite_object_base const_, opencog::combo::message,
opencog::combo::procedure_call_base const_,
opencog::combo::action_symbol_base const_, opencog::combo::ann_type>,
std::allocator<opencog::tree_node_<boost::variant<double,
opencog::combo::enum_t, opencog::combo:[image: 🆔]:builtin,
opencog::combo:[image: 🆔]:wild_card, opencog::combo::argument,
opencog::combo:[image: 🆔]:action, o pencog::combo::builtin_action_base
const_, opencog::combo::perception_base const_,
std::cxx11::basic_string, std::allocator >,
opencog::combo::indefinite_object_base const, opencog::combo::message,
opencog::combo::procedure_call_base const,
opencog::combo::action_symbol_base const_, opencog::combo::ann_type> > >

&)'
collect2: error: ld returned 1 exit status
moses/comboreduct/main/CMakeFiles/combo-fmt-converter.dir/build.make:92:
recipe for target 'moses/comboreduct/main/combo-fmt-converter' failed
make[2]: *** [moses/comboreduct/main/combo-fmt-converter] Error 1
CMakeFiles/Makefile2:519: recipe for target
'moses/comboreduct/main/CMakeFiles/combo-fmt-converter.dir/all' failed
make[1]: ***
[moses/comboreduct/main/CMakeFiles/combo-fmt-converter.dir/all] Error 2
Makefile:136: recipe for target 'all' failed
make: *** [all] Error 2

—
Reply to this email directly or view it on GitHub
#29.

from moses.

Undefined ref to opencog::combo::operator>> is key. All the << operators have to be in the std namespace. About 4-5 years ago, this problem was rampant, and putting these into namespace std fixed all issues. search the header files for declarations.

I'm guessing that moving operator>> to the std namespace will also fix it

from moses.

is it a problem with the newer cmake version included on ubuntu 15? i had built it before on ubuntu 14 and the problem was not present.

from moses.

Yes, the problem was cmake. On ubuntu 15.04, the cmake updated version is
3.0.2, while on ubuntu 15.10 the actual version is 3.2.2.
I updated the cmake on the ubuntu 15.04 to 3.2.2 (from the site) and got
this error.
I'll try to do what Linas suggested.

On Tue, Dec 1, 2015 at 12:11 AM, chris hawley [email protected]
wrote:

is it a problem with the newer cmake version included on ubuntu 15? i had
built it before on ubuntu 14 and the problem was not present.

—
Reply to this email directly or view it on GitHub
#29 (comment).

from moses.

The problem is in vertex.h. It has a declaration to
"operator>>(std::istream& in, combo::combo_tree& tr)", but it wasn't
defined in vertex.cc or any other file.
It shouldn't be a problem because it was there to "Disambiguate stream
operator; use the one declared in util/tree.h"
I don't know it it could be solved modifying the cmake list, but after I
defined it to use the operator>> of tree, it compiled.

But it didn't make one of the tests. When it tries to link
feature_selectionUTest (just this one, the rest are fine), there's tons of
undefined reference.
All of the functions that it says that have undefined reference are well
defined and working in others tests.
So, I think that's a cmake configuration thing. Sadly, I don't have enough
experience with cmake to point where this error could be.
Could someone look at it for me? it happens with cmake 3.2+ (tested with
3.2.2 and 3.4.1).

On Wed, Dec 2, 2015 at 9:07 AM, Arley Ristar [email protected] wrote:

Yes, the problem was cmake. On ubuntu 15.04, the cmake updated version is
3.0.2, while on ubuntu 15.10 the actual version is 3.2.2.
I updated the cmake on the ubuntu 15.04 to 3.2.2 (from the site) and got
this error.
I'll try to do what Linas suggested.

On Tue, Dec 1, 2015 at 12:11 AM, chris hawley [email protected]
wrote:

is it a problem with the newer cmake version included on ubuntu 15? i had
built it before on ubuntu 14 and the problem was not present.

—
Reply to this email directly or view it on GitHub
#29 (comment).

from moses.

I've read about cmake a little. It compiles and passed all the tests now.

About the first operator>> error:
It hasn't a definition inside the comboreduction lib, but it has a
definition in the comboant lib (comboant uses comboreduct), somehow with
the previous cmake the functions that use the input operator inside
comboreduction used the definition that is in comboant. It shouldn't
happen, first, because in the CMakeList comboreduct doesn't depends on
comboant lib and two, it creates a cycle.
So, to solve this problem changing just cmake, you can
add ant_combo_vocabulary to the comboreduct library.
But for me, this solution is too much workaround-oriented programming, I
would like to maintain my previous solution that changed the code in
iostream_combo.h and vertex.cc, can I do that?

About the second problem with the tests:
The feature_selection lib depends on the moses lib and moses depends on
feature_selection. But the feature selection hasn't moses as
target_link_libraries (how it didn't had any errors with it before?) and
you can't put it there because you cause a cyclic graph of shared
libraries. But you can put these two libraries as static and it will
compile (you can pass the full path too, but it will generate tons of
cyclic warnings).
Can I change these libs to static and make a pull request?

On Mon, Jan 4, 2016 at 3:59 PM, Arley Ristar [email protected] wrote:

The problem is in vertex.h. It has a declaration to
"operator>>(std::istream& in, combo::combo_tree& tr)", but it wasn't
defined in vertex.cc or any other file.
It shouldn't be a problem because it was there to "Disambiguate stream
operator; use the one declared in util/tree.h"
I don't know it it could be solved modifying the cmake list, but after I
defined it to use the operator>> of tree, it compiled.

But it didn't make one of the tests. When it tries to link
feature_selectionUTest (just this one, the rest are fine), there's tons of
undefined reference.
All of the functions that it says that have undefined reference are well
defined and working in others tests.
So, I think that's a cmake configuration thing. Sadly, I don't have enough
experience with cmake to point where this error could be.
Could someone look at it for me? it happens with cmake 3.2+ (tested with
3.2.2 and 3.4.1).

On Wed, Dec 2, 2015 at 9:07 AM, Arley Ristar [email protected] wrote:

Yes, the problem was cmake. On ubuntu 15.04, the cmake updated version is
3.0.2, while on ubuntu 15.10 the actual version is 3.2.2.
I updated the cmake on the ubuntu 15.04 to 3.2.2 (from the site) and got
this error.
I'll try to do what Linas suggested.

On Tue, Dec 1, 2015 at 12:11 AM, chris hawley [email protected]
wrote:

is it a problem with the newer cmake version included on ubuntu 15? i
had built it before on ubuntu 14 and the problem was not present.

—
Reply to this email directly or view it on GitHub
#29 (comment).

from moses.

Can't we move operator>> to libcomboreduct from libcomboant? I'm very surprised its not there already. Again -- please take care to put it in the correct namespace; I beleive it belonds in namespace std:: and not namespace combo:: as otherwise it won't work.

I find the feature_selection <-> moses dependency very annoying, and there must suely be some "clean" solution for it. I just don't know what it is.

Don't make it static. Just use the -Wl,--start-group and -Wl,--end-group flags like so:
https://cmake.org/pipermail/cmake/2011-May/044474.html
http://stackoverflow.com/questions/5651869/gcc-what-are-the-start-group-and-end-group-command-line-options
https://www.mail-archive.com/[email protected]/msg11956.html

from moses.

Now that I think about it, operator>> should already be defined in Tree.h so you need to figure out why the one in Tree.h is not being used.

from moses.

"Can't we move operator>> to libcomboreduct from libcomboant?"
Not directly. It's a specialization of operator>> that uses libcomboant classes
as template arguments to stream_to_combo_tree from iostream_combo.h.
But I already fixed that.

"I beleive it belonds in namespace std:: and not namespace combo:: as
otherwise it won't work."
It works as combo::, but most of these io operators are in std:: or
opencog::, so I agree in leave then on std.

"Now that I think about it, operator>> should already be defined in Tree.h
so you need to figure out why the one in Tree.h is not being used."
It isn't used because it was overridden inside vertex.h. If I remove the
prototype operator>> for the combo_tree, it uses the one in util/tree.h.
But I still have to leave another definition of operator>> for vertex (that
is a boost::variant), because it can't do the lexical_cast inside
util/tree.h without it.

"Don't make it static. Just use the -Wl,--start-group and -Wl,--end-group
flags like so:"
Sorry, I didn't know it had that option. Based on links 1 and 3 I looked
at interface_link_libraries and I painlessly solved it.

It's fixed, passed in all tests and works for the old and new cmake. I'll
create the pull request.

On Sat, Jan 9, 2016 at 10:43 PM, Linas Vepštas [email protected]
wrote:

Now that I think about it, operator>> should already be defined in Tree.h
so you need to figure out why the one in Tree.h is not being used.

—
Reply to this email directly or view it on GitHub
#29 (comment).

from moses.

Hi Arely, sorry, I got rather confused while writing the above. Doing too many things at the same time :-) Yes, specializations should stay where they are. The specializations probably should stay in namespace combo -- I retract my earlier statement about moving them to the std namespace. Anyway, your patch in #32 looks OK to me.

from moses.

I'll put it back, but see what I said about get_instance in the pull
request thread first.
Then I'll update the PR according.

On Tue, Jan 12, 2016 at 2:36 PM, Linas Vepštas [email protected]
wrote:

Hi Arely, sorry, I got rather confused while writing the above. Doing too
many things at the same time :-) Yes, specializations should stay where
they are. The specializations probably should stay in namespace combo --
I retract my earlier statement about moving them to the std namespace.
Anyway, your patch in #32 #32
looks OK to me.

—
Reply to this email directly or view it on GitHub
#29 (comment).

from moses.

Closing; I think this is stale ... an earlier comment states that after other plull reqs, everything builds and tests out.

from moses.