[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Axiom-developer] Axiom/GCL on windows
From: |
Gabriel Dos Reis |
Subject: |
Re: [Axiom-developer] Axiom/GCL on windows |
Date: |
11 Dec 2006 13:10:45 -0600 |
Vanuxem Gregory <address@hidden> writes:
| Le dimanche 10 décembre 2006 à 10:16 -0600, Gabriel Dos Reis a écrit :
|
| [...]
|
| > start address -T 10629000 Finished loading xrun.o
| > Loading interop.o
| > start address -T 1062f000 Finished loading interop.o
| > Loading patches.o
| > start address -T 10638000 Finished loading patches.o
| > Using local database
../../../axiom.bi/src/share/algebra/compress.daase.. Re-reading
compress.daase Using local database
../../../axiom.bi/src/share/algebra/interp.daase.. Re-reading interp.daase
| >
| > Error: Caught fatal error [memory may be damaged]
| > Fast links are on: do (si::use-fast-links nil) for debugging
| > Error signalled by RETURN.
| > Broken at APPLY. Type :H for Help.
|
| The segfault occurs in cacheKeyedMsg (src/interp/patches.lisp). This is
| a path problem, |fetchKeyedMsg| (patches.lisp) calls cacheKeyedMsg with
| |$defaultMsgDatabaseName| as argument. This argument is a pathname (path
| to target/*/share/msg/s2-us.msgs). GCL can not open this file since it's
| a unix path (/some/where) and segfault (I don't know where).
Thanks for your insight into this puzzle. I would have expected a
notification on failure, instead of proceeding ahead and craching.
Before rebuilding the database, the "old" DAASE is set to point to
the databases coming with the source code
axiom.bi/src/share/algebra/*.daase.
This is even mysterous because other database files in the same
directory (compress.daase) seem to have been opened successfully.
| With GCL on
| Windows you have to use mixed path (c:/some/where)
I noticed that GCL itself will figure out part of the path (the "C:/"
part), sometimes not. The inconsistency puzzled me at the time but I
did not relate it to a mysterous "segmentation fault". This is very
tricky. Because, we're compiling under MinWG/MSYS and the path would
come out as /some/path, not C:/some/path.
| (I know that truename
| accept Windows path with two backslash as separator (c:\\some\\where) so
| may be other functions too).
|
| I don't know exactly where is the problem but you're rerooting (function
| reroot) Axiom when you compile some interpreter's files. Reroot accepts
| an argument which has to be the root of Axiom.
yes, that invariant is met too.
| You give him (to reroot)
| a unix path and that's a problem (consequently $spadroot is wrong).
So, in essence, are you saying that we must convert the path to
something usable by GCL? Isn't this something that GCL should take
care of?
Thanks!
-- Gaby
- RE: [Axiom-developer] Axiom/GCL on windows, (continued)
- RE: [Axiom-developer] Axiom/GCL on windows, Vanuxem Gregory, 2006/12/15
- RE: [Axiom-developer] Axiom/GCL on windows, Gabriel Dos Reis, 2006/12/15
- RE: [Axiom-developer] Axiom/GCL on windows, Bill Page, 2006/12/15
- RE: [Axiom-developer] Axiom/GCL on windows, Vanuxem Gregory, 2006/12/16
- RE: [Axiom-developer] Axiom/GCL on windows, Bill Page, 2006/12/16
- Re: [Axiom-developer] Axiom/GCL on windows, Gabriel Dos Reis, 2006/12/16
Re: [Axiom-developer] Axiom/GCL on windows, Vanuxem Gregory, 2006/12/11
Re: [Axiom-developer] Axiom/GCL on windows, Vanuxem Gregory, 2006/12/11