Re: [Gcl-devel] GCL on mingw

[Vadim V. Zhytnikov]

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.

Ah, I see!

> > 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.)

Yes, without turning off fast-links gcl build fails.
I'll try to reproduce failure with debug later.


> > 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>