Question
Is there a way to force stack to rebuild all local precompiled packages?
Context
I had a working stack installation but I've updated my ArchLinux (including kernel update) and I get this now:
stack ghci
Main.hs: <command line>: can't load .so/.DLL for: /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../lib/libncurses.so (-lncursesw: cannot open shared object file: No such file or directory)
Since the given exists my guess is that the compiled version isn't linked correctly, that's why I try to rebuild everything.
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.
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 have
mainLogger.hs
Logger.hs
in my local directory where the mainLogger.hs reference the Logger module.
When in stack ghci I :load mainLogger.hs I get the following error message :
mainLogger.hs:6:18:
Could not find module ‘Logger’
It is not a module in the current program, or in any known package.
However if I can compile stack exec -- ghc mainLogger.hs and run stack runghc mainLogger2.hs or have stack exec -- ghci load the module correctly.
Anyone knows what is preventing stack ghci from locating module in the local directory ?
ps : I am not using any cabal file or stack.yaml file in this directory, so it falls back onto my global stack.yaml config
You should be able to load both if you do it at the same time:
:load Logger.hs mainLogger.hs
I don't know if you can get GHCi to look for the missing module in the current folder if you have no cabal file but if you create/initialize one this is not necessary.
This issue should now be fixed in the latest version of stack. It seems that when a module imported a local module, stack wasn't including the local directory in its module search path. In the latest 1.5.1. version of stack, this has been fixed - so you should be able to just type
stack ghci mainLogger.hs
Is it possible to use stack with an already installed ghc without stack installing a local copy of ghc or cabal?
Yes. If the ghc in PATH is of right version for the selected snapshot, stack will happily use it.
% ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.8.4
% stack --resolver=lts-2.22 install packdeps
Run from outside a project, using implicit global project config
Using resolver: lts-2.22 specified on command line
packdeps-0.4.1: unregistering
packdeps-0.4.2: download
...
% stack --resolver=nightly-2015-12-25 install packdeps
Run from outside a project, using implicit global project config
Using resolver: nightly-2015-12-25 specified on command line
Compiler version mismatched, found ghc-7.8.4 (x86_64), but expected minor version match with ghc-7.10.3 (x86_64) (based on resolver setting in /Users/phadej/.stack/global/stack.yaml).
Try running "stack setup" to install the correct GHC into /Users/phadej/.stack/programs/x86_64-osx/
You can also skip ghc check --skip-ghc-check:
% stack --resolver=nightly-2015-12-25 --skip-ghc-check install packdeps
Run from outside a project, using implicit global project config
Using resolver: nightly-2015-12-25 specified on command line
split-0.2.2: configure
...
but that might be a bad idea
What is the difference between adding package_name under the build-depends: section in a project's .cabal file, versus doing stack install package_name within that project's directory?
stack install will just install the package to the appropriate place (the current snapshot database for libraries in Stackage, the sandbox in ./.stack-work for other libraries, ~/.local/bin or your system's equivalent thereof for executables). Adding a library to build-depends specifies it as a dependency of your project, and leads to the library being installed next time you do a stack build. If you are actually using the library in your project you must add it to build-depends, otherwise you won't be able to build the project (or even play with the library using stack ghci).
N.B.: As of stack-0.1.3.1, stack install NAME is just a synonym for stack build --copy-bins NAME. The --copy-bins option tells stack to copy any executables to ~/.local/bin. If your package is just a library with no executables, stack install NAME is the same as stack build NAME.