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

[Waldek Hebisch]

Gabriel Dos Reis wrote:
> On Sun, 25 Feb 2007, Waldek Hebisch wrote:
> 
> [...]
> 
> | 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
> 
> In this case, it is not clear to me how the resulting C program would
> compile if GCL's header is not included.  So, it is probably a good
> thing that GCC complained.  But, I think the root cause is elsewhere.
>

My point is that GCC is inconsistent here: both non-existent and unreadable
directory raise the some alternative: either directory is not needed
(and may be safely skipped) or is needed.  I can guess that GCC made
a pragmatic decision here: non existent directories are probably very
frequent and GCC does not dare to signal error. 
 
> | - 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.
> 
> My understanding (Camm, please correct me) is that GCL is not set up
> yet to work without its internal header file.  However, if that is
> true I can't explain why we did not run into that problem before...
> 

Try the following (or belive me that you get indicated result). Create
a simple Spad file.  Take Axiom from build-improvements (or wh-sandbox),
with gcl intalation visible.  By default you should see 
compiler::*default-system-p* set to t.

1) Try just compiling your file.  It should compile fine.
2) Change access right on gcl instaltion so that it is unreadable by
you.  Again try compiling: you should see error about lack of
access to gcl directory
3) rename gcl directory. Again try compiling: you should see a
cascade of errors from gcc (due to missing declarations from
include file).
4) do
)lisp (setf compiler::*default-system-p* nil)
compile again: Your file should compile fine.
5) Move back gcl instalation into is original place (still
ureadable by you).  Compile again: you should see the same
error as in 2.

Point 4 shows that executable created by gcl _can_ compile Lisp
files if compiler::*default-system-p*  is set to nil and
include directory is either absent or readible.  With include
directory present, but unreadable (point 5 above) you get errors.

As I wrote, when compiler::*default-system-p* is nil C files generated
by gcl do not need the gcl include file.  But gcl still add corresponding
-I option to gcc comand line, and you get spurious errors.

-- 
                              Waldek Hebisch
address@hidden