[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Axiom-developer] Re: [Gcl-devel] GCL on mingw
From: |
Camm Maguire |
Subject: |
[Axiom-developer] Re: [Gcl-devel] GCL on mingw |
Date: |
12 Dec 2003 10:59:22 -0500 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
Greetings!
"Vadim V. Zhytnikov" <address@hidden> writes:
> 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
Just checked, and the configure default for mingw is cust-reloc. I'm
imagining that --disable-custreloc --enable-locbfd will fail.
> fails at the very beginning of 8th pass during RB GBC with
> the message
> Can't allocate. Good-bye!
Sorry for the confusing request. I wanted to see if you can reproduce
the crash when building pcl from source as part of the ansi build
process when *not* turning off fast-links. I'm inferring that
cust-reloc must be used on mingw, so I imagine that you will easily
reproduce Mike's reported problem. Still, it would be helpful to
reproduce this in a directory with --enable-debug turned on so we can
see what the problem is (i.e. whether it is memory related or not.)
> 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.
Take care,
>
> --
> Vadim V. Zhytnikov
>
> <address@hidden>
> <address@hidden>
>
>
>
--
Camm Maguire address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah