[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gcl-devel] Re: Configure and Mingw32 BFD and ANSI
From: |
Mike Thomas |
Subject: |
Re: [Gcl-devel] Re: Configure and Mingw32 BFD and ANSI |
Date: |
Fri, 12 Jul 2002 09:47:46 +1000 |
Hi Camm.
> > In answer to your questions of about a fortnight ago, unfortunately BFD
fasl
> > doesn't work on Win32, complaining of corrupted memory.
> >
>
> This is disheartening. Can you please give me the specific command
> and error output?
-----------------------------------------------------------
GCL (GNU Common Lisp) Version(2.5.0) Thu Jul 11 14:21:34 2002
Licensed under GNU Library General Public License
Contains Enhancements by W. Schelter
>(system "cat t.lsp")
(defun t (a b) (+ a b))
0
0
>(compile-file "t.lsp")
Compiling t.lsp.
End of Pass 1.
End of Pass 2.
OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3
Finished compiling t.lsp.
#p"t.o"
>(load "t.o")
Loading t.o
Error: Caught fatal error [memory may be damaged]
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by EVAL.
Broken at LOAD. Type :H for Help.
>>:q
Top level.
>
-----------------------------------------------------------
I've started to focus on differences between what happens before and after
the macro SEEK_TO_END_OFILE in "sfasl.c" as opposed to "sfaslbfd.c". Today
I intend to check whether there is an "off by one" difference or something
similar.
The good side of this is that I now understand what the 12 NULLS (and
certain variations) on certain platforms were used for - a marker between
the binary and the GCL data portions of the object files.
I *think* but don't know how to confirm that the binutils version is
2.12.90.
>
>
> > Neither does the ANSI branch of the build system, which dies during
loading
> > of "braid.o". I have previously got around this problem by loading PCL
> > rather than compiling, but it is, never-the-less, not good.
> >
>
> Again, error output here?
Note that this is the traditional build of the ANSI binary, and that up
until braid.o, other binaries are compiled and loaded. However a series of
"dont do bss _Lclptr???" messages appear while loading previous binaries,
and I don't know yet whether this can be ignored or not (see below).
Do those messages appear on other platforms?
-----------------------------------------------------------
Finished compiling c:/cvs/gcl/pcl/fast-init.o.
Loading binary of FAST-INIT...
dont do bss _Lclptr218dont do bss _Lclptr227dont do bss _Lclptr228dont do
bss _Lclptr229dont do bss _Lclptr9dont do bss _Lclptr243dont do bss
_Lclptr245dont do bss _Lclptr247dont do bss _Lclptr251dont do bss
_Lclptr256dont do bss _Lclptr257dont do bss _Lclptr259dont do bss
_Lclptr261dont do bss _Lclptr104dont do bss _Lclptr269dont do bss
_Lclptr270dont do bss _Lclptr272dont do bss _Lclptr274dont do bss
_Lclptr281dont do bss _Lclptr282dont do bss _Lclptr283dont do bss
_Lclptr286dont do bss _Lclptr290dont do bss _Lclptr291dont do bss
_Lclptr292dont do bss _Lclptr304dont do bss _Lclptr195dont do bss
_Lclptr96dont do bss _Lclptr314Compiling BRAID...
Compiling c:/cvs/gcl/pcl/braid.lisp.
End of Pass 1.
End of Pass 2.
OPTIMIZE levels: Safety=1 (No runtime error checking), Space=0, Speed=3
Finished compiling c:/cvs/gcl/pcl/braid.o.
Loading binary of BRAID...
make[1]: *** [compile] Error 128
make[1]: Leaving directory `/c/cvs/gcl/pcl'
make: *** [pcl/saved_gcl_pcl] Error 2
-----------------------------------------------------------
>
> > I will try and trace these problems with gdb which I have recently
managed
> > to understand a little better. Unfortunately I don't understand the
>
> Thanks! This is the way to go.
Only if you understand the flow of control, which as yet I do not.
> I've tried to keep the old build path intact as an option until the
> new stuff works everywhere the old did.
Yes, good idea.
Thanks for the reply
Mike Thomas
[Gcl-devel] comp.lang.lisp floating arithmetic bench, Mike Thomas, 2002/07/10