3.5.3

A unit that exports an integer constant or an array can be used from other modules again on 64-bit builds.

• In a unit's symbol file (.bsf) an integer constant was written as a long and read back as an int, and the bounds of an array or subrange were written as 4 bytes each and read back as a long. On a 64-bit build those sizes differ, so the first exported constant or array left the reader 4 or 8 bytes off, and every symbol declared after it in the unit came out as garbage: a program using the unit failed with E428 identifier ... is not procedure, function, variable or unit name on the first of the unit's procedures. It affected x86_64 and ARM64, not armeabi-v7a.
• Both are 4 bytes on every build now, so a .bsf is the same file whichever architecture wrote it.

Prebuilt binaries for:

• Linux x86_64 (dynamic and static) and ARM64 (static)
• Android arm64-v8a, armeabi-v7a and x86_64 (API 21, NDK r29; the 64-bit ones use 16 KB-aligned LOAD segments)

All six were verified by compiling Selftest in both math modes and the full CatchRect project: every build's class files are byte-identical to the output of 3.5.2, and they carry the required StackMap attributes. A unit exporting constants, an array type, an array of records and two routines, with a program using all of them, also compiles to identical output on all six.

Full Changelog: 3.5.2...3.5.3