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 <strings.h> 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 <strings.h> 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 _______________________________________________ cabal-devel mailing list [email protected] http://www.haskell.org/mailman/listinfo/cabal-devel
