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

[Hackage]

#532: libraries and include checks can be highly misleading
----------------------------+-----------------------------------------------
  Reporter:  guest          |        Owner:         
      Type:  defect         |       Status:  new    
  Priority:  normal         |    Milestone:         
 Component:  Cabal library  |      Version:  1.6.0.2
  Severity:  normal         |   Resolution:         
  Keywords:                 |   Difficulty:  unknown
Ghcversion:                 |     Platform:         
----------------------------+-----------------------------------------------
Changes (by duncan):

  * platform:  Windows =>
  * summary:  Can't find libraries on Windows (Cabal 1.6.0.2) => libraries
              and include checks can be highly misleading

Comment:

 For reference the reported error looks like:

 {{{
 ~/prgs/build/com-1.2.2
 $ cabal configure
 Resolving dependencies...
 Configuring com-1.2.2...
 cabal.exe: Missing dependencies on foreign libraries:
 * Missing header file: include/WideStringSrc.h
 * Missing C libraries: kernel32, user32, ole32, oleaut32, advapi32
 This problem can usually be solved by installing the system packages that
 provide these libraries (you may need the "-dev" versions). If the
 libraries
 are already installed but in a non-standard location then you can use the
 flags --extra-include-dirs= and --extra-lib-dirs= to specify where they
 are.
 }}}

 What it's doing is making a little test.c file that `#includes` the files
 and compiling it with gcc and linking in the libraries specified in the
 .cabal file.

 Something like:
 {{{
 gcc.exe test.c -lkernel32 -luser32 -lole32 -loleaut32
   -ladvapi32 --enable-stdcall-fixup --disable-stdcall-fixup
 }}}

 But this fails with the error message:
 {{{
 gcc.exe returned ExitFailure 1 with error message:
 cc1.exe: error: unrecognized command line option "-fenable-stdcall-fixup"
 cc1.exe: error: unrecognized command line option "-fdisable-stdcall-fixup"
 }}}

 So because the test C program fails to link then Cabal concludes that the
 header files and library cannot be found. The actual reason of course is
 that the com.cabal file specifies linker options that gcc does not
 understand.

 With that fixed we only get the problem about missing
 `include/WideStringSrc.h`:

 {{{
 ./include/WideStringSrc.h:13: error: syntax error before "wchar_t"
 ./include/WideStringSrc.h:18: error: syntax error before '*' token
 ./include/WideStringSrc.h:24: error: syntax error before '*' token
 }}}

 The reason, as you discovered is because the include files are listed in
 the wrong order. The include files really do depend on each other and so
 must be listed in the right order, just as they must be listed in the
 right order when #included in a .c file. If we include
 `include/StdTypes.h` first then that defines the types before they're
 used.

 So, in a sense everything is working perfectly however the error messages
 are highly misleading in this case. I've updated the bug summary to
 reflect that.

 We're open to suggestions on how it could be improved. We could print the
 error message that gcc gives us. In normal cases that will just be extra
 useless information, but in this case it would have alerted us to the fact
 that the ld-options were bogus and that there was a problem with the order
 of header includes. Also, if the header file really exists locally or we
 can easily find it globally then that is another strong hint that there's
 a problem compiling the header file rather than simply finding it.

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