gcl-devel
[Top][All Lists]
Advanced

[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




reply via email to

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