Re: next nightly build problem

[<don...@is...>]

Bruno Haible writes:
 > 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. 

I'd have expected it to work either way.
Don't I have the most common hardware?  
Or does this also depend on OS ?

 > 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.

so do something like this?
 make -f Makefile.devel  -k multibuild-porting64-gcc
That ends up with
  *** - SYSTEM::INITIAL-BREAK-DRIVER: The value of *DEBUG-IO* was not an appropriate stream: #<UNBOUND>. It has been changed to #<IO SYNONYM-STREAM *TERMINAL-IO*>.
  1. Break> 
I guess I have to keep typing ^D to these breaks
Or is there some better choice?
I worry that these ^D's are resulting in not providing the info you want.

Also it's not all that clear what I'm looking for in the results.
For instance, the first one, build-porting64-gcc-safety3 ends with
the newest file being  cbcstep3.log which ends with:
  make[2]: *** [run-all.fas] Error 1
  make[2]: Target 'clisp' not remade because of errors.
  make[2]: Leaving directory '/home/don/hg/clisp/build-porting64-gcc-safety3/benchmarks'
  Makefile:2194: recipe for target 'bench' failed
  make[1]: *** [bench] Error 2
  make[1]: Target 'check' not remade because of errors.
  make[1]: Leaving directory '/home/don/hg/clisp/build-porting64-gcc-safety3'

What would be useful output for you?
The transcript of the make?
The tails of all of the cbcstep3.log files?
They mostly look a lot like above.