build failure after "eval is actually compile"

build failure after "eval is actually compile"

[Ken Raeburn]

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"
[...hit ^C here...]
make[3]: *** Deleting file `guile-procedures.texi'
make[3]: *** [guile-procedures.texi] Interrupt

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)

... and then things would happily continue on.  At least, until it  
blew up somewhere else for unrelated reasons.

According to "git bisect", commit afe5e6b ("eval is actually compile")  
is where this first comes up.

Ken

Re: build failure after "eval is actually compile"

[Andy Wingo]

On Thu 27 Aug 2009 00:48, Ken Raeburn <raeburn@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/

Re: build failure after "eval is actually compile"

[Ken Raeburn]

On Aug 27, 2009, at 17:15, Andy Wingo wrote:
> I have reverted that part of the "eval is actually compile" commit  
> that
> seems to have caused you problems.

Thanks; that puts it back to the "print a warning and go on" case,  
which lets me get other work done.

> I wonder, though, what is loading up
> srfi-1 for you?

I wish I could tell, but as I mentioned in IRC, backtraces aren't  
working for me.  I suppose I can try instrumenting everything listing  
srfi-1 in use-modules, to print out a message first...

> Is it something about your shell, that the GUILE_AUTO_COMPILE=0 is not
> actually doing its job?

My interactive shell on the Mac is tcsh, but make should be using /bin/ 
sh for these commands.

> It seems so. Can you follow up on this and determine why exactly
> autocompilation is attempted, even though it should be disabled?

I'll try...

Ken

Re: build failure after "eval is actually compile"

[Mike Gran]

> From: Ken Raeburn <raeburn@raeburn.org>
> On Aug 27, 2009, at 17:15, Andy Wingo wrote:
> > I have reverted that part of the "eval is actually compile" commit that
> > seems to have caused you problems.
> 
> Thanks; that puts it back to the "print a warning and go on" case, which lets me 
> get other work done.
> 
> > I wonder, though, what is loading up
> > srfi-1 for you?

FWIW, I was getting the same errors as Ken described: both the loading of srfi-1
and the lockup when generating the docs without srfi-1 compiled.  It wasn't 
obvious what was calling srfi-1, but, I didn't try very hard to figure it out.

-Mike

Re: build failure after "eval is actually compile"

[Ken Raeburn]

On Aug 27, 2009, at 18:32, Ken Raeburn wrote:
>> I wonder, though, what is loading up
>> srfi-1 for you?
>
> I wish I could tell, but as I mentioned in IRC, backtraces aren't  
> working for me.  I suppose I can try instrumenting everything  
> listing srfi-1 in use-modules, to print out a message first...

The instrumentation was tedious, but helped -- it appears that  
message.scm and frame.scm are being loaded, and refer to srfi-1 in use- 
module specs.  If I comment the use-module lines out in those two  
files, then snarf-check-and-output-texi seems to run to completion.   
(Whether the change breaks them, I don't know.)

As for why stuff is getting loaded... it looks boot-9.scm's  
autocompiled-file-name is being called even if autocompilation is  
disabled, to find the name of an object that may have previously been  
cached.  So it loads up the compiler code, which loads up message.scm,  
which loads up srfi-1.scm, which needs that shared object.

>
>> Is it something about your shell, that the GUILE_AUTO_COMPILE=0 is  
>> not
>> actually doing its job?
>
> My interactive shell on the Mac is tcsh, but make should be using / 
> bin/sh for these commands.

I instrumented the C code where this variable is checked, and  
scm_getenv_int is indeed returning 0 there.  I put some printing calls  
into do_try_autocompile, and it was never called.

Ken