Hi Isaac,
I'm afraid that the latest release of Cabal breaks halfs-0.2. It's one
of a small handful of packages affected by the fact that Cabal now
checks that header files and C libs are present at configure time.
However halfs-0.2 is the only package I've found where the failure was
not strictly the package's fault.
What happens with halfs-0.2 is that it declares in the .cabal file that
it needs binutils.h which is a local header file. This is used by
Binary.hs. However Binary.hs also #includes first. Also, the
context in which binutils.h will be used in the intermediate .hc file
which will also #include "HsFFI.h". Now it turns out that binutils.h
requires both headers to be included first otherwise types that it uses
are not defined.
So what goes wrong is that Cabal checks if it can compile a test.c file
that #includes all the header files that halfs.cabal says it needs. Of
course this fails because binutils.h cannot be included on its own, it
needs strings.h and HsFFI.h to be included first.
The solution I would suggest is to modify binutils.h to #include both
and "HsFFI.h" first. I think we can rely on #ifdef guards to
prevent double-inclusion. Then it will be usable from each context,
the .hc file and the Cabal configure test.
The alternative would be to list strings, HsFFI.h and binutils in
the .cabal file (in which case it would not need to be listed in
Binary.hs).
Another alternative is to not list it at all in the .cabal file.
Arguably it's already wrong because the header file does not get
installed yet technically it may be required if ghc decides to inline C
calls across package boundaries (though this latter problem does not
apply from ghc-6.10 onwards).
Duncan
