Rob, Thanks for testing this and your comments. I'm replying to your individual comments below.
On 09/03/2019 16:11, Rob Arthan wrote:
- The configure script doesn?t validate an option beginning "?enable-?.
So I didn?t notice that I?d mistyped ?enable-compact32bit until I realised that I was getting executables and saved states with almost identical sizes. (I appreciate that this may be an autoconfig thing that you can?t control.)
Yes, I seem to remember that it is and that it wasn't possible to avoid it because there is a separate "configure" for libffi.
- If you build Poly/ML with ?disable-compact32bit and then try to build it
with ?enable-compact32 without doing ?make clean", it will fail during the ?make install? step like this:
Making install in . ./polyimport polytemp.txt -I . < ./exportPoly.sml Assertion failed: (j >= -(((POLYSIGNED)0x80 << (POLYSIGNED)(8*(sizeof(PolyWord)-1) -1)) -1)-1 && j <= (((POLYSIGNED)0x80 << (POLYSIGNED)(8*(sizeof(PolyWord)-1) -1)) -1)), function GetValue, file pexport.cpp, line 461. /bin/sh: line 1: 46725 Abort trap: 6 ./polyimport polytemp.txt -I . < ./exportPoly.sml make[1]: *** [polyexport.o] Error 134 make: *** [install-recursive] Error 1
Doing ?make clean? solves this problem.
I would always run "make distclean" before rerunning configure. Basically, what is happening is that it is picking up the wrong pre-built compiler.
- On MacOS with ?disable-intinf-asint and ?enable-compact32bit,
the ProofPower build fails like this:
Assertion failed: (space != 0), function ScanObjectAddress, file quick_gc.cpp, line 414.
- On Fedora with ?enable-intinf-asint and ?enable-compact32bit,
the ProofPower build fails like this:
pp-ml: quick_gc.cpp:414: virtual PolyObject* QuickGCScanner::ScanObjectAddress(PolyObject*): Assertion `space != 0' failed.
This is a last chance to test the current git master before release. Don't forget to run "make compiler" at least twice after the initial "make" in order to build the up-to-date compiler and recompile all the code with it. This is particularly important if testing the --enable-compact32bit version. Some extra checking was added during testing and there is a strong chance of getting an assertion failure during the initial "make" or the first "make compiler" due to a bug in the pre-built compiler. If this happens just rerun the step. Once the compiler has been rebuilt it will incorporate a fix.
These are the assertion failure I mentioned. Did this happen after running "make compiler"?
Regards, David