#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