anchor.diff:          make install
   +
   In the latter case, the destination directory defaults to the
  -"site-lisp" directory of your Emacs installation.
  -
  -9. After installation, do *not* strip the ocamldebug and ocamlbrowser
  -executables.  (These are mixed-mode executables, containing both
  -compiled C code and OCaml bytecode; stripping erases the bytecode!)
  -Other executables such as ocamlrun can safely be stripped.
  +`site-lisp` directory of your Emacs installation.
  +
  +9. After installation, do *not* strip the `ocamldebug` and `ocamlbrowser`
  +   executables. These are mixed-mode executables (containing both compiled C
  +   code and OCaml bytecode) and stripping erases the bytecode!  Other
  +   executables such as `ocamlrun` can safely be stripped.
   
   == IF SOMETHING GOES WRONG
   
  -Read the "common problems" and "machine-specific hints" section at the
  -end of this file.
  -
  -Check the files m.h and s.h in config/. Wrong endianness or alignment
  -constraints in m.h will immediately crash the bytecode interpreter.
  -
  -If you get a "segmentation violation" signal, check the limits on the
  -stack size and data segment size (type "limit" under csh or
  -"ulimit -a" under bash). Make sure the limit on the stack size is
  -at least 4M.
  -
  -Try recompiling the runtime system with optimizations turned off
  -(change CFLAGS in byterun/Makefile and asmrun/Makefile).
  -The runtime system contains some complex, atypical pieces of C code
  -that can uncover bugs in optimizing compilers. Alternatively, try
  -another C compiler (e.g. gcc instead of the vendor-supplied cc).
  -
  -You can also build a debug version of the runtime system. Go to the
  -byterun/ directory and do "make ocamlrund". Then, copy ocamlrund to
  -'../boot/ocamlrun', and try again. This version of the runtime system
  -contains lots of assertions and sanity checks that could help you
  -pinpoint the problem.
  +Read the "common problems" and "machine-specific hints" section at the end of
  +this file.
  +
  +Check the files `m.h` and `s.h` in `config/`. Wrong endian-ness or alignment
  +constraints in `m.h` will immediately crash the bytecode interpreter.
  +
  +If you get a "segmentation violation" signal, check the limits on the stack size
  +and data segment size (type `limit` under csh or `ulimit -a` under bash). Make
  +sure the limit on the stack size is at least 4M.
  +
  +Try recompiling the runtime system with optimizations turned off (change
  +`CFLAGS` in `byterun/Makefile` and `asmrun/Makefile`). The runtime system
  +contains some complex, atypical pieces of C code which can uncover bugs in
  +optimizing compilers.  Alternatively, try another C compiler (e.g. `gcc` instead
  +of the vendor-supplied `cc`).
  +
  +You can also build a debug version of the runtime system. Go to the `byterun/`
  +directory and do `make ocamlrund`.  Then, copy `ocamlrund` to
  +`../boot/ocamlrun`, and try again.  This version of the runtime system contains
  +lots of assertions and sanity checks that could help you pinpoint the problem.
   
   
   == COMMON PROBLEMS
  
positive.code: * The Makefiles do not support parallel make (e.g. make -j2).
  Fix: do not pass the -j option to make, and be patient.
  
  * The Makefiles use the "include" directive, which is not supported by
  all versions of make. Use GNU make if this is a problem.
  
  * Solaris make mishandles a space in our Makefiles, so you have to use GNU
  make to build on Solaris.
  
  * The Makefiles assume that make executes commands by calling /bin/sh. They
  won't work if /bin/csh is called instead. You may have to unset the SHELL
  environment variable, or set it to /bin/sh.
  
  * On some systems, localization causes build problems.  You should
  try to set the C locale (export LC_ALL=C) before compiling if you have
  strange errors while compiling OCaml.
  
  * gcc 2.7.2.1 generates incorrect code for the runtime system in -O mode
  on some Intel x86 platforms (e.g. Linux RedHat 4.1 and 4.2).
  If this causes a problem, the solution is to upgrade to 2.7.2.3 or above.
  
  * Some versions of gcc 2.96 for the Intel x86 (as found in RedHat 7.2,
  Mandrake 8.0 and Mandrake 8.1) generates incorrect code for the runtime
  system.  The "configure" script tries to work around this problem.
  
  * On HP 9000/700 machines under HP/UX 9.  Some versions of cc are
  unable to compile correctly the runtime system (wrong code is
  generated for (x - y) where x is a pointer and y an integer).
  Fix: use gcc.
  
  * Under MacOS X 10.6, with XCode 4.0.2, the configure script mistakenly
  detects support for CFI directives in the assembler.
  Fix: give the "-no-cfi" option to configure.
  
negative.code:         make bootstrap > log.bootstrap 2>&1     # in sh
          make bootstrap >& log.bootstrap         # in csh
  +
  The `make bootstrap` checks that the bytecode programs compiled with the new
  compiler are identical to the bytecode programs compiled with the old compiler.
  If this is the case, you can be pretty sure the system has been correctly
  compiled. Otherwise, this does not necessarily mean something went wrong.  The
  best thing to do is to try a second bootstrapping phase: just do
  `make bootstrap` again.  It will either crash almost immediately, or
  re-re-compile everything correctly and reach the fix-point.
  
  4. If your platform is supported by the native-code compiler (as reported during
     the auto-configuration), you can now build the native-code compiler.  From
     the top directory, do:
  
          make opt
  +
  