On Thu 27 Aug 2009 00:48, Ken Raeburn <raeb...@raeburn.org> writes:
> Building on GNU/Linux, with a fresh build tree, and without an installed
> tree under $prefix, fails for me. I get:
>
> ./guile_filter_doc_snarfage --filter-snarfage) > regex-posix.doc || { rm
> regex-posix.doc; false; }
> cat alist.doc [...] regex-posix.doc | GUILE_AUTO_COMPILE=0 ../meta/
> uninstalled-env guile-tools snarf-check-and-output-texi >
> guile-procedures.texi || { rm guile-procedures.texi; false; }
> ERROR: In procedure dynamic-link:
> ERROR: file: "libguile-srfi-srfi-1-v-4", message: "libguile-srfi-
> srfi-1-v-4.so: cannot open shared object file: No such file or
> directory"
I have reverted that part of the "eval is actually compile" commit that
seems to have caused you problems. I wonder, though, what is loading up
srfi-1 for you?
Is it something about your shell, that the GUILE_AUTO_COMPILE=0 is not
actually doing its job?
> This failure is caused because the srfi-1 code is needed before the
> build has hit the srfi directory. (The need for hitting ^C is a
> deadlock problem I'll describe in a separate message.) In slightly
> older versions I would get:
>
> ;;; WARNING: compilation of /var/raeburn/guile/linux/meta/guile-tools
> failed:
> ;;; key misc-error, throw_args ("dynamic-link" "file: ~S, message: ~S"
> ("libguile-srfi-srfi-1-v-4" "libguile-srfi-srfi-1-v-4.so: cannot open
> shared object file: No such file or directory") #f)
It seems so. Can you follow up on this and determine why exactly
autocompilation is attempted, even though it should be disabled?
Thanks,
Andy
ps. Sorry you seem to be hitting all our corner cases. Your testing is
appreciated.
--
http://wingolog.org/
