Re: [Axiom-developer] Axiom/GCL on windows

[Gabriel Dos Reis]

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