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.
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
else
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));
fclose(f);
return 0;
}
EOF
===========================================================
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
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
core_end'.