Re: [MIT-Scheme-devel] [commit 13b5bca] Fix new build to cross from 9.1.1.

[Taylor R Campbell]

A brief note on terminology to clarify the rest of my message:

host - the platform on which you are running the build
target - the platform for which you are building something
cross-compiler - a host program that compiles code into a target program
native compiler - compiler that generates code for the same platform it runs on
boot-compiler - a cross-compiled native compiler, as the current
  default svm and liarc builds use

   Date: Sun, 23 Feb 2014 17:42:10 -0700
   From: Matt Birkholz <address@hidden>

   In the LIAR/C and LIAR/svm cross builds, the whole system is native
   compiled by a boot-compiler.  Why do we want to encourage
   cross-compilation?  Why do you NOT follow the example of LAIR/C's and
   LIAR/svm's cross-builds?

Eventually the cross-compiler and the native compiler should yield
bit-for-bit identical results.  That way, we can skip the extra step
of cross-compiling a boot-compiler before using that to natively
compile the system.

Bit-for-bit identical and reproducible results are a good idea all
around.  Always building a cross-compiler means we keep those code
paths healthy.  Skipping the boot-compiler means that if I want to,
e.g., use my beefy 24-thread Xeon build machine to cross-compile a
Scheme to run on a scrawny Raspberry Pi, I can do that without having
to use the rpi to compile anything itself.

   Why can't you (and why do you try to) cross-compile IMAIL?

Compiling IMAIL currently depends on having all of Edwin, SOS, &c.,
loaded into the compiler's address space.

We could build Edwin, SOS, &c., twice -- once with the host's native
compiler (call it host-Edwin &c.), and once with the cross-compiler
(call it target-Edwin &c.), like we now do for cref/sf/compiler -- and
then load host-Edwin &c. into the cross-compiler to cross-compile
IMAIL, and install target-Edwin &c. in the end.  But that wastes a lot
of time to build Edwin twice for the sole purpose of cross-compiling
IMAIL.

Instead I chose to use the newly built native compiler for the target
to build IMAIL by loading the newly built target-Edwin &c.  This is
not the right thing in the long run, but it will do for now.  It's
also not the only step that is currently necessary to run on the
target: the cold load also has to run there, since we don't have any
concept of a linker.

The right thing in the long run is to make it unnecessary to load all
of Edwin in order to compile code that uses Edwin macros.  However,
this requires major surgery to the way macro expansion works, which
means I won't get to it for a while.

   > What is the substantive difference between what compile-svm.sh does
   > and what the parallelized Makefile.tools/Makefile build does?

   It only cross-compiles a boot compiler.  On the target, the boot
   compiler is fasloaded and used to compile everything natively.  The
   installed binaries were written by the boot compiler and the new
   machine, not a cross compiler on the old machine "finished" on the new
   machine...  If you had a really simple cross fasdumper, perhaps you
   could pretend the difference is nothing.

OK, so it's not really substantially different from using the
parallelized Makefile.tools/Makefile to cross-compile Scheme, and then
using the result to natively compile Scheme again.

   But perhaps you are just asking "How can your slightly different
   cross-compile have fixed the bogus linkage-section problem?"  My
   answer: I'm afraid I only dislodged it!

OK.  We should have a bug in Savannah for it for the record.  I will
take a look at it at some point.