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
