+ FFI change: header files are now <emphasis>not
+ used</emphasis> when compiling via C.
+ The <option>-#include</option> flag,
+ the <literal>includes</literal> field
+ in <literal>.cabal</literal> files, and header files
+ specified in a <literal>foreign import</literal>
+ declaration all have no effect when compiling Haskell
+ source code.</para>
+
+ <para>This change has important ramifications if you are
+ calling FFI functions that are defined by macros (or renamed
+ by macros). If you need to call one of these functions,
+ then write a C wrapper for the function and call the wrapper
+ using the FFI instead. In this way, your code will work
+ with GHC 6.10.1, and will also work
+ with <option>-fasm</option> in older GHCs.</para>
+
+ <para>This change was made for several reasons.
+ Firstly, <option>-fvia-C</option> now behaves consistently
+ with <option>-fasm</option>, which is important because we
+ intend to stop compiling via C in the future. Also, we
+ don't need to worry about the interactions between header
+ files, or CPP options necessary to expose certain functions
+ from the system header files (this was becoming quite a
+ headache). We don't need to worry about needing header
+ files when inlining FFI calls across module or package
+ boundaries; calls can now be inlined freely. One downside
+ is that you don't get a warning from the C compiler when you
+ call a function via the FFI at the wrong type.
+ </para>
+
+ <para>Another consequence of this change is that
+ calling <emphasis>varargs</emphasis> functions (such
+ as <literal>printf</literal>) via the FFI no longer works.
+ It has never been officially supported (the FFI spec outlaws
+ it), but in GHC 6.10.1 it may now really cause a crash on
+ certain platforms. Again, to call one of these functions
+ use appropriate fixed-argument C wrappers.</para>
+ </listitem>
+ <listitem>
+ <para>