[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: build failure after "eval is actually compile"

From: Andy Wingo
Subject: Re: build failure after "eval is actually compile"
Date: Thu, 27 Aug 2009 23:15:54 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux)

On Thu 27 Aug 2009 00:48, Ken Raeburn <address@hidden> 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-
> 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" " 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?



ps. Sorry you seem to be hitting all our corner cases. Your testing is

reply via email to

[Prev in Thread] Current Thread [Next in Thread]