Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Different behaviour when using "stack build "pkg"" and "stack build" to implicitly build the pkg #1561

simonjantsch opened this issue Dec 25, 2015 · 5 comments


Copy link

I'm trying to build an existing project, that has dependencies which are provided by github links, with stack and I encountered following:

When build the project with stack build the dependency seems to build fine, I get following in the in the end of the buildlog:

In-place registering bindings-llvm-0.1...
Installing library in
Registering bindings-llvm-0.1...

When however running stack build bindings-llvm I get following error:

Could not resolve file /home/simon/Uni/BachArbeit/vvt/.stack-work/downloaded/d3f241eec39c8de03ed09f9a4c4c0fe4b40e69f77a840d113d98d87cd8e21092/In file included from wrapper/HaskellPass.h

and the package does not build. I get the same, when cloning the repo of the dependency from github and try to build it with
stack. Shouldn't stack build $pkg and implicitly building the package with stack build yield the same results?

Any help is appreciated! Thanks in advance,


Copy link

quyse commented Dec 26, 2015

Seeing this too right now with my own package which builds C++ files as well as Haskell.

flaw-bullet- configure
Configuring flaw-bullet-
flaw-bullet- build
Preprocessing library flaw-bullet-

Could not resolve file /home/quyse/workspace/flaw/flaw-bullet/In file included from src/bullet/src/LinearMath/btQuaternion.h

I tried to build the package with cabal, and it turns out that there's a compile error in C++, and gcc prints out a message mentioning paths to some C++ header files (actually In file included from src/bullet/src/LinearMath/btQuaternion.h is a beginning of gcc's message). I guess stack tries to resolve gcc's output lines as paths (as it prepended this line with package's root directory), rather than just print them untouched, hence instead of list of C++ compile errors I see this useless message.

$ stack --version
Version 1.0.0, Git revision 3bc26237b5b3c387b8fd564459ea4dd88fd58b30 (2939 commits) x86_64

Copy link

Ah interesting, I looked at the log when building with cabal and I get this message at the same place where the error comes when using 'stack build bindings-llvm'

*** C Compiler:
'/usr/bin/gcc' '-fno-stack-protector' '-Wl,--hash-size=31' '-Wl,--reduce-memory-overheads' '-x' 'c++' 'wrapper/HaskellPass.cpp' '-o' '/tmp/ghc3287_0/ghc3287_0.s' '-S' '-O' '-D__GLASGOW_HASKELL__=706' '-DTABLES_NEXT_TO_CODE' '-I/usr/lib/llvm-3.5/include' '-DNDEBUG' '-D_GNU_SOURCE' '-D__STDC_CONSTANT_MACROS' '-D__STDC_FORMAT_MACROS' '-D__STDC_LIMIT_MACROS' '-g' '-O2' '-fomit-frame-pointer' '-std=c++11' '-fvisibility-inlines-hidden' '-fno-exceptions' '-fPIC' '-Woverloaded-virtual' '-ffunction-sections' '-fdata-sections' '-Wcast-qual' '-DHS_LLVM_VERSION=305' '-O2' '-I' 'dist/build' '-I' '/usr/lib/llvm-3.5/include' '-I' 'wrapper' '-I' '.' '-I' '/usr/lib/ghc/unix-' '-I' '/usr/lib/ghc/time-' '-I' '/usr/lib/ghc/bytestring-' '-I' '/usr/lib/ghc/base-' '-I' '/usr/lib/ghc/include'

In file included from wrapper/HaskellPass.h:4:0:
from wrapper/HaskellPass.cpp:1:

warning: "__STDC_LIMIT_MACROS" redefined

I see this warning in the log when implicitly building the package, by calling 'stack build' in the parent directory. So it seems that stack handles warnings differently when building the package implicitly as dependency or directly. Also warnings should be ignored by default, no? And the log message is not really helpful.

Copy link

I've committed a change that should fix this. Please try it and close the issue if so.

The problem was that the exception handling for resolving paths in warning messages was incorrect, and it would crash if it encountered a bad path instead of just passing it through unchanged. For warnings, this didn't effect multi-package builds because the build log is only shown if there is an error, so it would never try to resolve the paths in the warnings (whereas single-package builds do always show the warnings).

Copy link

quyse commented Dec 31, 2015

@borsboom With latest version of stack the issue is gone for me. Cool!

Copy link

It works for me too, thank you! I'm closing the issue

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

5 participants