I have a project to build with stack and it depends on network. When I do stack build, it says
[1 of 1] Compiling Main ( /tmp/stack23678/network-2.6.2.1/Setup.hs, /tmp/stack23678/network-2.6.2.1/.stack-work/dist/i386-linux/Cabal-1.22.5.0/setup/Main.o )
Linking /tmp/stack23678/network-2.6.2.1/.stack-work/dist/i386-linux/Cabal-1.22.5.0/setup/setup ...
Configuring network-2.6.2.1...
...
checking whether the C compiler works... no
configure: error: in `/tmp/stack23678/network-2.6.2.1':
configure: error: C compiler cannot create executables
See `config.log' for more details
Sure, I'd love to. But where is this config.log? Or how can I re-create it?
Just cabal install network (without stack) works fine but how could stack build use this?
In order to get better information here, you can make sure all generated files are saved by manually building network:
stack unpack network-2.6.2.1
cd network-2.6.2.1
stack init
stack build
I think C compiler cannot create executables means you don't have a working C compiler installed.
config.log is generated by the configure command, and I don't think stack saves that. stack does save other logging output in
~/.stack/global-project/.stack-work/logs/...
It's the same as what was emitted to your terminal, so it may not help.
Related
I'm unable to do stack build for any projects on Ubuntu 20.04 or 18.04 running as a VirtualBox guest on Windows 10. Building fails when trying to rename a temp file: .stack-cabal-mod11115-0.tmp: rename: resource busy (Text file busy)
edit: this appears to only happen on VirtualBox shared folders. Stack can successfully build a project in a folder that is not shared with the Windows hot.
I've previously had no issues with 1.9.x versions of stack in identical environments. At this point I'm not even able to get stack build to compile a new project on a clean Ubuntu installation. If I downgrade to 1.9.3 everything magically works. I've deleted ~.stack and .stack-work folders and retried without success.
Below is the output on a new project using stack new. I'm able to use stack repl, although I still get an error message about the build failing with
vagrant#ubuntu-focal:/vagrant/test$ stack --version
Version 2.7.1, Git revision 8afe0c2932716b0441cf4440d6942c59568b6b19 x86_64 hpack-0.34.4
vagrant#ubuntu-focal:/vagrant/test$ stack setup
Preparing to install GHC (tinfo6) to an isolated location.
This will not interfere with any system-level installation.
Downloaded ghc-tinfo6-8.10.4.
Installed GHC.
stack will use a sandboxed GHC it installed
For more information on paths, see 'stack path' and 'stack exec env'
To use this GHC and packages outside of a project, consider using:
stack ghc, stack ghci, stack runghc, or stack exec
vagrant#ubuntu-focal:/vagrant/test$ stack build
[1 of 2] Compiling Main ( /home/vagrant/.stack/setup-exe-src/setup-mPHDZzAJ.hs, /home/vagrant/.stack/setup-exe-src/setup-mPHDZzAJ.o )
[2 of 2] Compiling StackSetupShim ( /home/vagrant/.stack/setup-exe-src/setup-shim-mPHDZzAJ.hs, /home/vagrant/.stack/setup-exe-src/setup-shim-mPHDZzAJ.o )
Linking /home/vagrant/.stack/setup-exe-cache/x86_64-linux-tinfo6/tmp-Cabal-simple_mPHDZzAJ_3.2.1.0_ghc-8.10.4 ...
Building all executables for `test' once. After a successful build of all of them, only specified executables will be rebuilt.
test> configure (lib + exe)
Configuring test-0.1.0.0...
/vagrant/test/.stack-work/dist/x86_64-linux-tinfo6/Cabal-3.2.1.0/.stack-cabal-mod11009-2.tmp: rename: resource busy (Text file busy)
vagrant#ubuntu-focal:/vagrant/test$ stack build
Building all executables for `test' once. After a successful build of all of them, only specified executables will be rebuilt.
test> configure (lib + exe)
Configuring test-0.1.0.0...
/vagrant/test/.stack-work/dist/x86_64-linux-tinfo6/Cabal-3.2.1.0/.stack-cabal-mod11115-0.tmp: rename: resource busy (Text file busy)
Thanks.
I'm a haskell beginner, I use the advent of code as learning examples.
When setting up for this year I reinstalled stack (on a new machine, however copied most dotfiles over) and was starting from my last years notes and was not able to get hdevtools working again.
I have set up a new project with stack new advent2019. In case it matters stack build on the "empty" project seems to take several minutes - seems much longer than last year. I install hdevtools with stack build hdevtools.
When I run stack exec hdevtools -- check src/Lib.hs I get following error:
Cabal error: hdevtools: Use of GHC's environment variable GHC_PACKAGE_PATH is incompatible
with Cabal. Use the flag --package-db to specify a package database (it can be
used multiple times).
So far I tried:
I checked my shell and did an rg --no-ignore over my home directory to confirm GHC_PACKAGE_PATH is not set by me. Also over the project directory.
I was not able to figure out how to use the mentioned --package-db flag - putting it after hdevtools I get an unknown flag error, putting it to stack I get an invalid option.
stack exec --no-ghc-package-path hdevtools -- check src/Lib.hs - mentioned here
I deleted all possible related files: ~/.local/bin/hdevtools, everything from ~/.stack, all ~/.ghc*.
None helped with the error.
I suppose I overlooked something obvious - however can you help point it out?
For completeness:
on OS X, 10.15.1
stack --version: Version 1.9.3, Git revision 40cf7b37526b86d1676da82167ea8758a854953b (6211 commits) x86_64 hpack-0.31.1
stack ghc -- --version: The Glorious Glasgow Haskell Compilation System, version 8.6.5
stack path:
stack-root: /Users/me/.stack
project-root: /Users/me/Code/advent2019
config-location: /Users/me/Code/advent2019/stack.yaml
bin-path: /Users/me/.stack/snapshots/x86_64-osx/lts-14.16/8.6.5/bin:/Users/me/.stack/compiler-tools/x86_64-osx/ghc-8.6.5/bin:/Users/me/.stack/programs/x86_64-osx/ghc-8.6.5/bin:/usr/local/texlive/2018basic/bin/x86_64-darwin:/Users/me/.local/bin/:/Users/me/.gem/bin:/Users/me/.yarn/bin:/Users/me/Library/Python/3.7/bin/:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/Library/TeX/texbin:.:/Applications/Wireshark.app/Contents/MacOS
programs: /Users/me/.stack/programs/x86_64-osx
compiler-exe: /Users/me/.stack/programs/x86_64-osx/ghc-8.6.5/bin/ghc
compiler-bin: /Users/me/.stack/programs/x86_64-osx/ghc-8.6.5/bin
compiler-tools-bin: /Users/me/.stack/compiler-tools/x86_64-osx/ghc-8.6.5/bin
local-bin: /Users/me/.local/bin
extra-include-dirs:
extra-library-dirs:
snapshot-pkg-db: /Users/me/.stack/snapshots/x86_64-osx/lts-14.16/8.6.5/pkgdb
local-pkg-db: /Users/me/Code/advent2019/.stack-work/install/x86_64-osx/lts-14.16/8.6.5/pkgdb
global-pkg-db: /Users/me/.stack/programs/x86_64-osx/ghc-8.6.5/lib/ghc-8.6.5/package.conf.d
ghc-package-path: /Users/me/Code/advent2019/.stack-work/install/x86_64-osx/lts-14.16/8.6.5/pkgdb:/Users/me/.stack/snapshots/x86_64-osx/lts-14.16/8.6.5/pkgdb:/Users/me/.stack/programs/x86_64-osx/ghc-8.6.5/lib/ghc-8.6.5/package.conf.d
snapshot-install-root: /Users/me/.stack/snapshots/x86_64-osx/lts-14.16/8.6.5
local-install-root: /Users/me/Code/advent2019/.stack-work/install/x86_64-osx/lts-14.16/8.6.5
snapshot-doc-root: /Users/me/.stack/snapshots/x86_64-osx/lts-14.16/8.6.5/doc
local-doc-root: /Users/me/Code/advent2019/.stack-work/install/x86_64-osx/lts-14.16/8.6.5/doc
dist-dir: .stack-work/dist/x86_64-osx/Cabal-2.4.0.1
/Users/me/Code/advent2019/.stack-work/install/x86_64-osx/lts-14.16/8.6.5/hpc
local-bin-path: /Users/me/.local/bin
ghc-paths: /Users/me/.stack/programs/x86_64-osx
The --no-ghc-package-path solution should have worked. However, you can just run hdevtools outside of Stack. On a Linux machine, if I run the following set of commands exactly:
$ stack new advent2019
$ cd advent2019
$ stack build
$ stack install hdevtools
$ hdevtools check src/Lib.hs
then hdevtools starts without error and runs in the background.
If your shell can't find hdevtools, it may be that ~/.local/bin is not in your path, so add it or try this instead:
$ ~/.local/bin/hdevtools check src/Lib.hs
Turns out I overlooked the .cabal directory in my purge. Though still had to also wipe .stack before installing hdevtools. Also had to build test separately so I would get dependency errors.
I don't think this is a solution for someone who uses haskell productively. Reminds me of my Windows 95 days where support told you to format and reinstall for every issue.
When I try compiling my Haskell program with Stack, I get the following error:
Building executable 'fractal' for fractal-0.1.0.0..
[1 of 2] Compiling Main ( app/Main.hs, .stack-work/dist/x86_64-linux-tinfo6/Cabal-2.2.0.1/build/fractal/fractal-tmp/Main.o )
<command line>: can't load .so/.DLL for: /usr/lib/gcc/x86_64-unknown-linux-gnu/8.2.0/../../../../lib/libtinfo.so (-lncursesw: cannot open shared object file: No such file or directory)
-- While building custom Setup.hs for package fractal-0.1.0.0 using:
/home/lorxu/.stack/setup-exe-cache/x86_64-linux-tinfo6/Cabal-simple_mPHDZzAJ_2.2.0.1_ghc-8.4.3 --builddir=.stack-work/dist/x86_64-linux-tinfo6/Cabal-2.2.0.1 build lib:fractal exe:fractal --ghc-options " -ddump-hi -ddump-to-file -fdiagnostics-color=always"
When I compile with GHC directly, it works fine, and libncursesw.so is present in /usr/lib. I'm on Void Linux. Any ideas where Stack is looking?
This looks like an issue with the bindist Stack has chosen for Void Linux - it normally guesses right, but it can cause issues on some distros. The tinfo6 variant tries to load libtinfo.so, since some distributions provide ncurses6 through that shared object file. You can try configuring the variant manually - you'll probably want standard. Stack will install a new GHC version if you do that, but it will change what shared object it tries to load for ncurses.
EDIT:
This was actually caused by an issue with GHC - if the distro links between the various ncurses files with a linker file, instead of an actual link, GHC won't follow it properly and instead complain that the file doesn't exist. The solution is to replace the linker file with a link to the target.
I depend on a package that needs alex to build, i also need ghcjs.
When i try to run stack ghci:
language-java-0.2.8: configure (lib)
Error:
-- While building package language-java-0.2.8 using:
<long command>
Process exited with code: ExitFailure 1
Logs have been written to: /Users/LeanderK/Documents/Haskell/exemplator-java_parser/.stack-work/logs/language-java-0.2.8.log
Configuring language-java-0.2.8...
Cabal-simple_mPHDZzAJ_1.24.2.0_ghcjs-0.2.1.9007019_ghc-8.0.1: The program
'alex' version >=3.1.3 is required but it could not be found.
Warning: Build failed, but optimistically launching GHCi anyway
The following GHC options are incompatible with GHCi and have not been passed to it: -threaded
Configuring GHCi with the following packages: exemplator-client
Using main module: 1. Package `exemplator-client' component exe:exemplator-client-exe with main-is file: ..../app/Main.hs
Progress: 1/2<command line>: cannot satisfy -package language-java-0.2.8
(use -v for more information)
I've tried: stack build alex (just returns, don't have any output. Might work), stack install alex (doesn't work).
Output of stack install alex
Couldn't find executable alex in directory .../.stack/snapshots/x86_64-osx/lts-7.19/ghcjs-0.2.1.9007019_ghc-8.0.1/bin/
For reference: This is the cabal file of the dependency, unfortunately only found on github. This is my stack and my cabal file. There is also a reddit discussion that didn't go anywhere.
I followed "Yesod quick start guide" to install Yesod in Windows 10.
But, when I issued the stack build command, it failed.
Environment
Windows 10 (64bits)
stack-0.1.5 (for Windows10 64bits)
No Haskell Platform
I executed these commands
stack new my-project yesod-sqlite && cd my-project
stack install yesod-bin cabal-install --install-ghc
stack setup
stack build <--- the error occured
In 'stack build' command, the package installations were done. But, when it build the project, the error occured.
Command Prompt
>stack build
Setting codepage to UTF-8 (65001) to ensure correct output from GHC
my-project-0.0.0: build
Preprocessing library my-project-0.0.0...
In-place registering my-project-0.0.0...
Preprocessing executable 'my-project' for my-project-0.0.0...
Linking .stack-work\dist\x86_64-windows\Cabal-1.22.4.0\build\my-project\my-project.exe ...
ghc.exe: could not execute: C:\Users\xxxxx\AppData\Local\Programs\stack\x86_64-windows\ghc-7.10.2\lib/../mingw/bin/gcc.exe
-- While building package my-project-0.0.0 using:
C:\Users\xxxxx\AppData\Roaming\local\bin\stack-0.1.5.0\setup-exe-cache\setup-Simple-Cabal-1.22.4.0-x86_64-windows-ghc-7.10.2.exe --builddir=.stack-work\dist\x86_64-windows\Cabal-1.22.4.0\ build lib:my-project exe:my-project --ghc-options -ddump-hi -ddump-to-file
Process exited with code: ExitFailure 1
This is caused by the argument length limit on Windows. Starting in GHC 7.10.3, GHC will support response files for sending linker arguments in order to bypass this limitation. In the meanwhile, a workaround is to manually make the path to your stack root shorter by setting the STACK_ROOT environment variable.
For more information, see https://www.fpcomplete.com/blog/2015/08/stack-ghc-windows