libquery-engine.so: undefined reference to opencog::AtomSpace

[kasimebrahim]

In the atomspace _ATOMSPACELIBRARY depends on execution and query-engine. And both depend on _ATOMSPACELIBRARY but neither of them add _ATOMSPACELIBRARY as a dependency to avoid cyclic dependency, instead there is this. I dont know how it works but assuming it is equivalent or at least similar to

add_library(_atomspace IMPORTED)
set_property(TARGET _atomspace PROPERTY IMPORTED_LOCATION 'path')
target_link_libraries(execute _atomspace)
target_link_libraries(query-engine _atomspace)

and according to the comments above it, it is supposed to handle the linking issue but in our case it is not.

Another thing I should mention is that on the dependencies added to _ATOMSPACELIBRARY specifically lambda and execution here the comment says they are needed for classerver but the classerver is in atombase. moreover when I try removing them every thing works all tests pass. But the comments say removing them results in screwball failures and I dont think it is just a threat considering it is written very recently.

[linas]

There is no _atomspace .. that's just wrong. The whole thing seems wrong to me. In particular, you should not be accessing execution and query-engine directly: this is pretty much guaranteed to fail. ... so .. what to do?

Just say

TARGET_LINK_LIBRARIES(myfoo  ${ATOMSPACE_LIBRARIES})

That's it -- the ${ATOMSPACE_LIBRARIES} is a variable set by the atomspace installers, and it always contains the current correct list of libraries in the appropriate order, etc.

[kasimebrahim]

Hi @linas, that is right but I dont think I explaind my question properly, the thing is, the above(by the above I mean 'TARGET_LINK_LIB...') is resulting in linking error libquery-engine.so:undefined ref to opencog::Atomspace::... you can check it out on the CI. My first step was to go to Atomspace and check if query-engine adds atomspace as a dependency and I found out it cant since it will result in circular dependency. So I started looking how it is handled and come across this https://github.com/singnet/atomspace/blob/37755a95e7acd3a648e9a6871e4092b5ab080a0a/lib/AtomSpaceConfig.cmake.in#L9. Hince the above

Sorry for the typo, I am writing this from my phone.

[linas]

You'd have to supply an example of an actual failure. It should work -- e.g. all of opencog builds just fine and I can't guess why things would be different for you.

[vsbogd]

As far as I see @kasimebrahim talks about https://circleci.com/gh/singnet/as-moses/412 failure

[linas]

I presume that is due to version skew. You cannot mix-n-match opencog and singnet repos; they contain different versions of the code; I can only guarantee that all of opencog is self-consistent.

[ngeiswei]

The problem occurs both when using latest singnet/atomspace and opencog/atomspace, so it's another problem than mix-n-match opencog and singnet repos.

[ngeiswei]

It is locally reproducible BTW, not just on circleci.

[ngeiswei]

I found a very bizarre fix. Add the following include in https://github.com/opencog/as-moses/blob/master/tests/combo/combo/annUTest.cxxtest

#include <opencog/combo/combo/iostream_combo.h>

then the following in test_ann()

       combo_tree tr;
       std::stringstream ss;
       ss >> tr;

problem gone!

The question is: why?

[linas]

Still totally confused.

First, everything builds, all unit tests pass for me. But OK, lets explore:

So I do this:

cd as-moses
git checkout master
git pull
grep -r ATOMSPACE_LIBRARY tests/*
grep -r ATOMSPACE_LIBRARY opencog/*

so I can't even find the code you are describing. I found one bad makefile -- fixed in #48

Still maybe I missed something: Nil talks about annUTest so lets look at that: its build by ./tests/combo/combo/CMakefile.txt and it says:

ADD_CXXTEST(annUTest)
TARGET_LINK_LIBRARIES(annUTest
   ascombo
   ${COGUTIL_LIBRARY}
)

still no atomspace anywhere in sight. Maybe there are missing symbols in ascombo ?

ldd -r ./opencog/combo/libascombo.so

Nope! Seems to be fully linked. No missing symbols. So I'm not seeing any problem anywhere... except for #48

[linas]

Hmm. OK, so I see circleCI failing in pull req #48 .. debugging now

[linas]

There seem to be multiple issues. The Atomspace was using some deprecated CMake configurations. The Atomspace had failed to list some dependencies. I think opencog/atomspace#2120 fixes that.

But also the as-moses CMakefile were faulty: incomplete library specfications were made. So pull req #48 is now passing, with a "belt and suspenders" approach to avoiding pants from falling down.

[linas]

BTW: the order in which libraries are listed is important! later libraries must provide symbols missing in earlier libraries.

[ngeiswei]

It indeed fixes it, thanks a lot!