Re: [Gcl-devel] GCL on mingw

[Camm Maguire]

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