Re: [Axiom-developer] Bug with paths in wh-sandbox

[Waldek Hebisch]

Gabriel Dos Reis wrote:
> On Sun, 25 Feb 2007, Waldek Hebisch wrote:
> 
> | Gabriel Dos Reis wrote:
> | > On Sat, 24 Feb 2007, Waldek Hebisch wrote:
> | > | After some investigation it turend out that eariler versions do not
> | > | need "cmpinclude.h" -- gcl simply puts inline content of this file.
> | > | gcl behaviour is controlled by the Lisp compiler::*default-system-p*
> | > | variable, which is set to t.  As a workaround one can use the following
> | > | in the start script:
> | > |
> | > | )lisp (setf compiler::*default-system-p* nil)
> | > |
> | > | AFAICS the problem was interoduced in version 25 (patch 45): this
> | > | variable is set to t when using system installed gcl.  Typically
> | > | this is not a problem, but I belive that if somebody builds gold
> | > | using system installed gcl (assuming that this would work ...)
> | > | and then puts the content of Axiom directory on a machine whithout
> | > | installed gcl, then the same problem would appear.
> | > |
> | > | Now, the question is how to solve the problem.  One way is to patch
> | > | src/lsp/Makefile.pamphlet so that it does not set
> | > | compiler::*default-system-p* to t.  Another possibility is to
> | > | set compiler::*default-system-p* to nil when dumping final AXIOMsys.
> | > | For me the second possibility looks slightly better, as it avoids
> | > | putting extra crud into intermediate C files.
> | > |
> | > | From my point of view nicest solution would be to teach gcl check
> | > | if cmpinclude.h is in expected place, if yes use it, otherwise
> | > | use cached version.
> | >
> | > You have spent some time investigating this; but, unfortunately I do
> | > not see the direct link to GCL stuff being system-wide or not.
> | > Please could you walk me (slowly) through your invesgitation?
> | >
> | > [ I just saw your patch, but I would first like to see why the
> | >   patch is correct at the "algorithmic" level. ]
> | >
> |
> | in the file gcl_cmpmain.lsp we have:
> |
> | (defun compiler-pass2 (c-pathname h-pathname system-p )
> |   (declare (special *init-name*))
> |   (with-open-file (st c-pathname :direction :output)
> |     (let ((*compiler-output1* (if (eq system-p 'disassemble) 
> *standard-output*
> |                                 st)))
> |       (declare (special *compiler-output1*))
> |     (with-open-file (*compiler-output2* h-pathname :direction :output)
> |       (cond ((and
> |               (stringp *cmpinclude-string*)
> |               (not system-p)
> |               (si::fwrite *cmpinclude-string* 0
> |                           (length *cmpinclude-string*) *compiler-output1*)))
> |             (t (wt-nl1 "#include " *cmpinclude*)))
> |
> | So, if system-p argument to compiler-pass2 is true, it will try to
> | use system include file.
> 
> Yes, I understood that part.
> 
> The link I'm missing is why Axiom's misbehaviour (reported by both
> Gregory and Martin) is traced back to that.  Or am I lured by the
> title of the thread? (I have been travelling the whole week, so I have
> no access to all the discussion, only this one and some other bits).
>

First, this fixes _part_ of the problem that Martin reported (problem
reported by Gregory are fixed by another patch).  

: Ein weiteres Problem, das bei putty aufgetreten ist, war die folgende 
Fehlermeldung:
: (1) ->
: (1) -> f(0)==0
:                                                                    Type: Void
: (2) -> f(1)==1
:                                                                    Type: Void
: (3) -> f(n)==f(n-1)+f(n-2)
:                                                                    Type: Void
: (4) -> f(7)
:    Compiling function f with type Integer -> NonNegativeInteger
:    Compiling function f as a recurrence relation.
: cc1: Fehler: 
/local/scratch/wh-sandbox/build/i686-pc-linux/lib/gcl-2.6.8/unixport/../h: 
Permission denied
 
This errors came for gcc search for include files.  The patch I applied
allows Axiom to work when build tree is not present.  In other words,
when you make a tarball of installed Axiom and put it on another
machine it will work, unless there is unreadable directory on path
leading to original build tree.

That is, one still gets the error when build tree is unreadable.  It is
hard to say who is a guilty party.  At least part of blame goes to the
following:

- gcc: it skips nonexistent directories, but raises errors for unreadable
  ones
- gcl: it unconditionally adds include directive of form
    -I/gcl/system/directory/../h
  (where /gcl/system/directory/ is stored in si::*system-directory*
  variable)
- Axiom, because it lets si::*system-directory* stay at its default
  setting.

One possibility to solve this problem is to point si::*system-directory*
(more precisely the pathname with "../h" appended) to known empty (or non
existent) directory (for example somwhere inside Axiom tree).  If we
decide to do that we may even create real h directory and put
cmpinclude.h there.  I initially rejected such idea (changing 
si::*system-directory*) because I prefer limit our intervention into
gcl internals (note that compiler::*default-system-p* is nil by
default, so my patch merely restored default setting).  I was
also not aware that evan after applying the patch the permission
problem is still present:  my assumption was that gcl should be
capable of generating working standalone executables which can
compile code on the fly.  It is obvious that such executable
needs C compiler in the system, but I consider it a bug that
mere presence of unreadable directory with a magic name can
break such a program.
 
> | now in the same file in compile-file1 we have
> |
> |         (compiler-pass2 c-pathname h-pathname system-p ))
> |
> | and the beginning of compile-file1 is:
> |
> | (defun compile-file1 (input-pathname
> |                       &key (output-file input-pathname)
> |                            (o-file t)
> |                            (c-file *default-c-file*)
> |                            (h-file *default-h-file*)
> |                            (data-file *default-data-file*)
> |                            (c-debug nil)
> |                            #+aosvs (ob-file nil)
> |                            (system-p *default-system-p*)
> |
> | so during compile system-p is taken from *default-system-p*, unless
> | a specific values is given as a keyword argument.
> 
> -- Gaby
> 

-- 
                              Waldek Hebisch
address@hidden