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

[Gabriel Dos Reis]

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.

| - 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...

-- Gaby