Re: next nightly build problem
Bruno Haible <[email protected]>
| Newsgroups | gmane.lisp.clisp.devel |
|---|---|
| Message-ID | <15194115.OArP9epnZK@omega> |
Hi Don,
> Any idea what the problem is
The problem is that the heuristic choice of object representation scheme
(HEAPCODES vs. TYPECODES) picks the wrong one in your case. You can
override it through one of the defines listed at the top of lispbibl.d:
Flags that determine the object representation:
Store only minimal type information in a pointer:
HEAPCODES
Store a good amount of type information in a pointer:
TYPECODES
More detailed object representation schemes:
Object representation schemes on 32-bit platforms:
STANDARD_HEAPCODES
LINUX_NOEXEC_HEAPCODES
TRY_TYPECODES_1 (try to avoid it: limits heap size to 16 MB)
TRY_TYPECODES_2 (try to avoid it: limits heap size to 16 MB)
Object representation schemes on 64-bit platforms:
STANDARD_HEAPCODES
GENERIC64_HEAPCODES
Specific variants of GENERIC64_HEAPCODES on 64-bit platforms:
GENERIC64A_HEAPCODES
GENERIC64B_HEAPCODES
GENERIC64C_HEAPCODES
Use 64-bit pointers on 32-bit platforms
(try to avoid it: wastes a lot of memory):
WIDE_SOFT, WIDE_SOFT_LARGEFIXNUM
To make it easy to find the right flag, I've added to the Makefile.devel
a target 'multibuild-porting64-gcc' (use with "make -k"!) that tries various
combinations of options. It takes about 1 hour to run. When it is done, take
a look at the build-porting64-gcc-*/cbcstep3.log to see which of the options
worked.
> how to fix it
I am currently revisiting it. (It's one of the major portability problems.)
> and when this might be done?
Not immediately. But hopefully soon. You will be notified.
Bruno
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
clisp-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/clisp-devel