Can't make guile example work

[ngeiswei]

I'm trying to follow what is described in

atomspace/examples/guile/README.md

but I'm getting the following error

nilg@laptop:~/OpenCog/atomspace/examples/guile$ guile
GNU Guile 2.0.9
Copyright (C) 1995-2013 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> (add-to-load-path "/usr/local/share/opencog/scm")
scheme@(guile-user)> (add-to-load-path ".")
scheme@(guile-user)> (use-modules (ice-9 readline))
scheme@(guile-user)> (activate-readline)
scheme@(guile-user)> (use-modules (opencog))
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;;       or pass the --no-auto-compile argument to disable.
;;; compiling /usr/local/share/opencog/scm/opencog.scm
;;; opencog.scm:22:0: warning: possibly unbound variable `cog-set-atomspace!'
;;; opencog.scm:22:20: warning: possibly unbound variable `cog-new-atomspace'
;;; compiled /home/nilg/.cache/guile/ccache/2.0-LE-8-2.0/usr/local/share/opencog/scm/opencog.scm.go
While compiling expression:
ERROR: In procedure dynamic-link: file: "libsmob", message: "file not found"

[linas]

The "file not found" message is misleading. it's failing because of this:

ldd -d libsmob.so

libPythonEval.so => not found

so why does scheme depend on PythonEval?

[linas]

try again, there was a constellation of bugs, mostly install and python init issues, that I fixed over the last week.

[ngeiswei]

It is fixed.

[Radivarig]

I've built atomspace with nix package manager and when trying to follow the basic.scm example am getting In procedure dynamic-link: file: "libsmob", message: "file not found" even tho the folder containing libsmob.so was set export LTDL_LIBRARY_PATH="$atomspace_build/opencog/guile". Any ideas how to debug this?

[linas]

The easeist work-around would be to just say make install. libsmob depends on half-a-dozen more libraries scattered in the build tree, which then depend on yet others. ... and there are potentially other complications with regard to other guile modules.

The unit tests can be run without install; special efforts were made to assure that. I'm not surprised that the examples won't work, without install.

[Radivarig]

@linas yes I've done make and make install but with nix there is no global shared location for libraries as each build output sits in its own read-only path so I need to provide those paths on places where something is expected to be.

For example, to make the atomspace build pass I've had to patch CMakeLists.txt files to include guile dependency gmp and add some directories over cmake cli, since the common shared folders like /usr/local/share do not exist:

function buildPhase() {
  sed -i '1i INCLUDE_DIRECTORIES(${GMP_INCLUDE_DIR})' ../opencog/**/CMakeLists.txt

  cmake \
    -DCMAKE_PREFIX_PATH:PATH="$GMP_LIBRARY;$GMP_INCLUDE_DIR;$GUILE_LIBRARY;$GUILE_INCLUDE_DIR" \
    -DCMAKE_INSTALL_PREFIX:PATH=$out ..

  make
}

function installPhase() {
  make install
  cd ..
  mv build $build
}

If I understand correctly, opencog.scm#L33 should setenv LTDL_LIBRARY_PATH that contains the location of libsmob.so.

I did provide that path:

shellHook = ''
  export LTDL_LIBRARY_PATH="${atomspace_build}/opencog/guile" # has libsmob.so
  guile -L ${atomspace_src}/opencog/scm # has opencog.scm
'';

But am still getting the error In procedure dynamic-link: file: "libsmob", message: "file not found", as if the path is being ignored.

Can you explain more about how you concluded this:

The "file not found" message is misleading. it's failing because of this:
ldd -d libsmob.so
libPythonEval.so => not found

?

I'm looking for a way to do similar debug to pinpoint the root of the issue and make appropriate patch for CmakeLists.txt, opencog.scm or other files.

[linas]

libPythonEval.so => not found

This seems to have been fixed; it no longer occurs for me.

"file not found" is a standard error string, returned by strerror()

"In procedure" is something that guile is printing; I'm now searching through the guile source to see where ... it seems to show up in module/ice-9/boot-9.scm but this is not very useful; its generic error-handling code.

"dynamic-link" would be another guile string (giveaway: no one else uses dashes in names) and it seems to be defined in libguile/dynl.c so we're getting warmer. All the heavy lifting is done by sysdep_dynl_link on line 265 which calls lt_dlopen or lt_dlopenext near line 85 ... This is C code, debuggable by printfs or gdb.

Now: here's the only part I don't understand: lt_dlopen is just a "thin" wrapper around ldd which is just a thin wrapper around the glibc loader. And since ldd isn't reporting any errors, its hard to imagine that lt_dlopen would.

[linas]

anyway, this should be a distinct issue, instead of piggy-backing on an old closed issue.

[linas]

One possible way of debugging might be this: create a very short C file, and see what happens:

#include <dlfcn.h>
#include <stdio.h>
int main () { 
    void * foo = dlopen("libsmob.so", RTLD_NOW);
    printf("got %p\n", foo);
    if (foo) printf("aok\n"); else printf("yuuck %s\n", dlerror()); 
}

If this prints "aok", then I'm stumped.

As I read man dlopen I'm wondering if somehow NIX managed to cause RTLD_LOCAL to be set, which might mess things up. But that seems like an unlikely guess.

[linas]

p.s I'm now reading Eelco Dolstra's PhD thesis -- its pretty exciting, so thanks for that reference! I'd never quite understood what this was about, before.

[Habush]

One possible way of debugging might be this: create a very short C file, and see what happens:

This helped me solve an obscure linker bug in Mac OS. Thank you!