[Top][All Lists]

[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 20:12:41 +0300
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru-RU; rv:1.5) Gecko/20031006

Camm Maguire ?????:

Hi Vadim!

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


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.

some strange problem on configure stage.
The following test fails
echo $ac_n "checking sizeof struct contblock""... $ac_c" 1>&6
echo "configure:3238: checking sizeof struct contblock" >&5
if test "$cross_compiling" = yes; then
  echo Cannot find sizeof struct contblock;exit 1
  cat > conftest.$ac_ext <<EOF
#line 3243 "configure"
#include "confdefs.h"
#include <stdio.h>
        #define EXTER
        #include "$MP_INCLUDE"
        #include "`pwd`/h/enum.h"
        #include "`pwd`/h/object.h"
        int main(int argc,char **argv,char **envp) {
        FILE *f=fopen("conftest1","w");
        fprintf(f,"%u",sizeof(struct contblock));
        return 0;
Trouble makes are these two lines
        #include "`pwd`/h/enum.h"
        #include "`pwd`/h/object.h"
Due to some reason under mingw
        #include "/home/vadim/gcl/h/enum.h"
signals an error: File not found.
I really don't understand such strange behavior
since ls /home/vadim/gcl/h/enum.h works fine.
But maybe we just can replace these two lines by
        #include "h/enum.h"
        #include "h/object.h"

I'll look into making this change.  Unfortunately, write access to cvs
at savannah is still down.  Please remind me if I forget by the time
it is restored.

With such modification I was able to build
ANSI GCL on mingw.  My goal was to test strange


Really?  You built pcl?  We definitely need the details here if so, as
Mike has experienced problems getting through this stage, and has had
to use precompiled .c source to ship his binary ansi package.

BTW, I do suspect the problem you report and Mike's build problem
stems from the same source.

memory-related GCL crashes under mingw.
I tried various memory allocation tests -
exactly the same I used on Linux (see e.g.
atest.lisp in attachment).  In general
results are practically the same on both
platforms with one important exception.
While on Linux I maximally can use 110K pages
(MAXPAGES=128K) on mingw all attempts
to allocate more than ~62000 pages
causes allocation error.  GCL self terminates
with the message:
Unrecoverable error: Can't allocate

My suspicion is that the heap is growing into some memory area already
in use for something else, e.g. shared libs.  I think Mike is away at
the moment, but I had previously requested the following from him,
which you may now be able to provide for me:

1) value of the configure determined define DBEGIN

#define DBEGIN _dbegin

with hard coded _dbegin = 0x10100000

2) on building a gcl with --enable-debug, run under gdb, breaking at
   main, and report the value of 'p sbrk(0)'


3) break at init_lisp, stop at this line:

        if (NULL_OR_ON_C_STACK(&j) == 0
            || NULL_OR_ON_C_STACK(Cnil) != 0
            || (((unsigned long )core_end) !=0
                && NULL_OR_ON_C_STACK(core_end) != 0))
          { /* check person has correct definition of above */
            error("NULL_OR_ON_C_STACK macro invalid");

   and report the values returned by 'p &j', 'p &Cnil_body', and 'p

I guess you mean initlisp.  But I really have a trouble with
this test.  If I make
 (gdb) br initlisp
GDB responds that it will stop at some address.
So far so good. But when I make
 (gdb) run
GCL starts but nothing happens - no breakpoint is activated.
What I'm doing wrong?

4) Try to let me know if the C stack counts up or down.  I.e. break in
   some function with a local variable defined, and print the address
   of that variable, and compare it to the address of a local variable
   defined in a surrounding function (i.e. a parent function).

Stack counts down as far as I understand.  At least this is frame
addresses for trivial recursive function:

0: 0x22fe48
1: 0x22fe68
2: 0x22fe88

     Vadim V. Zhytnikov


reply via email to

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