[Hackage] #532: libraries and include checks can be highly misleading

Hackage cvs-ghc at haskell.org
Thu Apr 15 02:36:27 EDT 2010

#532: libraries and include checks can be highly misleading
  Reporter:  guest          |        Owner:  kmcallister    
      Type:  defect         |       Status:  closed         
  Priority:  normal         |    Milestone:  Cabal-1.8      
 Component:  Cabal library  |      Version:        
  Severity:  normal         |   Resolution:  fixed          
  Keywords:                 |   Difficulty:  easy (<4 hours)
Ghcversion:                 |     Platform:                 
Changes (by duncan):

  * status:  assigned => closed
  * resolution:  => fixed


 Thanks! I've applied this and extended it so that we also check compiling

 For example for a header with wrong C syntax we get:

 Configuring foo-1.0...
 setup: Bad header file: error.h
 The header file contains a compile error. You can re-run configure with
 verbosity flag -v3 to see the error messages from the C compiler.

 Where as if the header has a pre-processing error (eg `#include
 "missing.h"`) then we get:

 Configuring foo-1.0...
 setup: Missing dependency on a foreign library:
 * Missing (or bad) header file: error.h
 This problem can usually be solved by installing the system package that
 provides this library (you may need the "-dev" version). If the library is
 already installed but in a non-standard location then you can use the
 --extra-include-dirs= and --extra-lib-dirs= to specify where it is.
 If the header file does exist, it may contain errors that are caught by
 the C
 compiler at the preprocessing stage. In this case you can re-run configure
 with the verbosity flag -v3 to see the error messages.

 Patches applied:

 Fri Apr  9 03:25:43 BST 2010  mcallister.keegan at gmail.com
   * better error messages for erroneous local C headers
   Addresses the issue in tickets #532, #648.
   When the all-together test of C libraries and headers fails, use only
   preprocessor to probe the headers individually.  If they all check out,
   give a more equivocal error message and suggest -v3.

 Thu Apr 15 07:24:01 BST 2010  Duncan Coutts <duncan at haskell.org>
   * Also check compiling C headers at configure-time
   So we now both check if the headers can be pre-processed and separately
   if they can be compiled. If it fails the pre-processing check then it
   is usually (but not always) a missing header. If it fails to compile
   then it is definately borked, not missing. Error messages reflect this.

Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/532#comment:7>
Hackage <http://haskell.org/cabal/>
Hackage: Cabal and related projects

More information about the cabal-devel mailing list