[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Gabriel Dos Reis
Subject: Re: [Axiom-developer] Bug with paths in wh-sandbox
Date: Sun, 25 Feb 2007 12:55:09 -0600 (CST)

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 
| : (1) ->
| : (1) -> f(0)==0
| :                                                                    Type: 
| : (2) -> f(1)==1
| :                                                                    Type: 
| : (3) -> f(n)==f(n-1)+f(n-2)
| :                                                                    Type: 
| : (4) -> f(7)
| :    Compiling function f with type Integer -> NonNegativeInteger
| :    Compiling function f as a recurrence relation.
| : cc1: Fehler: 
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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]