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.