gcl-devel
[Top][All Lists]
Advanced

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

Re: [Gcl-devel] GCL on mingw


From: Vadim V. Zhytnikov
Subject: Re: [Gcl-devel] GCL on mingw
Date: Fri, 12 Dec 2003 17:07:12 +0300
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru-RU; rv:1.5) Gecko/20031006

Camm Maguire ?????:

Greetings!

"Vadim V. Zhytnikov" <address@hidden> writes:


Camm Maguire ?????:


Hi Vadim!
"Vadim V. Zhytnikov" <address@hidden> writes:


Hi!

Trying to build recent GCL 2.6.1 on mingw I encountered

 ^^^^^^^^^^^^^^^
Great!  I was just going to ask you if you had a mingw development
system to work with given your earlier mingw problem report.


Well, I just followed Mike's readme.mingw instruction.
The key point is additional (si::use-fast-links nil) in


                              ^^^^^^^^^^^^^^^^^^^^^^^

Thanks for the reminder.  I had forgotten about this.  I'm wondering
if this is the only place where fast-links cause a problem.  If so, it
may simply be in the large array GCL allocates for the purposes of
toggling between fast and slow function pointers coupled with the
memory allocation issues you are observing..  If not, perhaps there is
some alignment issue, or (much worse), some ia64-like retrictions on
function calls via function pointers when the shared library maps
could change across runs.  We should be able to break at the bad
function jump in pcl_braid.c (see earlier thread with the debugging
details if interested), go up one frame, disassemble, and look at the
registers to see if the function address has somehow been corrupted.


pcl/makefile.  He also apparently recommends --enable-custreloc
but I was able to build  ANSI GCL with and without this option.


???  Meaning via statsysbfd (the default), or via dlopen?


On the other hand I did it with some gcl 2.6.1 snapshot not
with very last CVS sources - I have to try it once again.



It would be nice if you could also verify the ansi build crash when
not turning off fast-links and building without custreloc.


I've build latest ANSI GCL (Dec 03, 2003) without custreloc
(all default options except --enable-ansi).  CONS allocation test
fails at the very beginning of 8th pass during RB GBC with
the message
        Can't allocate.  Good-bye!
This is a bit different from traditional GCL. I think that
this difference is purely due to different initial
memory layouts of traditional and ansi images.

--
     Vadim V. Zhytnikov

      <address@hidden>
     <address@hidden>





reply via email to

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