Re: next nightly build problem

[Bruno H. <br...@cl...>]

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