I created a new project and, as you can see, it even downloaded a brand new build plan for lts-7.4, which as you can see uses ghc-8.0.1.
But when running stack ghci, it built the project with GHC 7.10, and dropped me in a 7.10 ghci shell.
dario#curie /tmp> stack new foo
Downloading template "new-template" to create project "foo" in foo/ ...
Looking for .cabal or package.yaml files to use to init the project.
Using cabal packages:
- foo/foo.cabal
Selecting the best among 9 snapshots...
Downloaded lts-7.4 build plan.
* Matches lts-7.4
Selected resolver: lts-7.4
Initialising configuration using resolver: lts-7.4
Total number of user packages considered: 1
Writing configuration to file: foo/stack.yaml
All done.
dario#curie /tmp> cd foo
dario#curie /t/foo> stack ghci
foo-0.1.0.0: configure
Configuring foo-0.1.0.0...
foo-0.1.0.0: build
Preprocessing library foo-0.1.0.0...
[1 of 1] Compiling Lib ( src/Lib.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/Lib.o )
In-place registering foo-0.1.0.0...
Preprocessing executable 'foo-exe' for foo-0.1.0.0...
[1 of 1] Compiling Main ( app/Main.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/foo-exe/foo-exe-tmp/Main.o )
Linking .stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/foo-exe/foo-exe ...
foo-0.1.0.0: copy/register
Installing library in
/tmp/foo/.stack-work/install/x86_64-linux/lts-7.4/7.10.3/lib/x86_64-linux-ghc-7.10.3/foo-0.1.0.0-6bylsnNRJPuHxByS3dKqs5
Installing executable(s) in
/tmp/foo/.stack-work/install/x86_64-linux/lts-7.4/7.10.3/bin
Registering foo-0.1.0.0...
The following GHC options are incompatible with GHCi and have not been passed to it: -threaded
Using main module: 1. Package `foo' component exe:foo-exe with main-is file: /tmp/foo/app/Main.hs
Configuring GHCi with the following packages: foo
GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Lib ( /tmp/foo/src/Lib.hs, interpreted )
Ok, modules loaded: Lib.
[2 of 2] Compiling Main ( /tmp/foo/app/Main.hs, interpreted )
Ok, modules loaded: Lib, Main.
>
I always relied on the assumption that for every stackage snapshot, stack would use only one version of GHC, am I wrong?
I don't have system-ghc: true in my config, and the faq doesn't mention many other alternatives
This is the output of stack path:
dario#curie /t/foo> stack path
stack-root: /home/dario/.stack
project-root: /tmp/foo
config-location: /tmp/foo/stack.yaml
bin-path: /home/dario/.stack/snapshots/x86_64-linux/lts-7.4/7.10.3/bin:/home/dario/.stack/programs/x86_64-linux/ghc-8.0.1/bin:/home/dario/Applications/bin:/home/dario/.rbenv/shims:/home/dario/.cabal/bin:/home/dario/.nix-profile/bin:/home/dario/.nix-profile/sbin:/home/dario/.sdkman/candidates/grails/current/bi n:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/usr/lib/jvm/java-8-oracle/bin:/usr/lib/jvm/java-8-oracle/db/bin:/usr/lib/jvm/java-8-oracle/jre/bin:/home/dario/.local/bin:/home/dario/.nix-profile/bin
programs: /home/dario/.stack/programs/x86_64-linux
compiler-exe: /usr/bin/ghc
compiler-bin: /usr/bin
local-bin: /home/dario/.local/bin
extra-include-dirs:
extra-library-dirs:
snapshot-pkg-db: /home/dario/.stack/snapshots/x86_64-linux/lts-7.4/7.10.3/pkgdb
local-pkg-db: /tmp/foo/.stack-work/install/x86_64-linux/lts-7.4/7.10.3/pkgdb
global-pkg-db: /var/lib/ghc/package.conf.d
ghc-package-path: /tmp/foo/.stack-work/install/x86_64-linux/lts-7.4/7.10.3/pkgdb:/home/dario/.stack/snapshots/x86_64-linux/lts-7.4/7.10.3/pkgdb:/var/lib/ghc/package.conf.d
snapshot-install-root: /home/dario/.stack/snapshots/x86_64-linux/lts-7.4/7.10.3
local-install-root: /tmp/foo/.stack-work/install/x86_64-linux/lts-7.4/7.10.3
snapshot-doc-root: /home/dario/.stack/snapshots/x86_64-linux/lts-7.4/7.10.3/doc
local-doc-root: /tmp/foo/.stack-work/install/x86_64-linux/lts-7.4/7.10.3/doc
dist-dir: .stack-work/dist/x86_64-linux/Cabal-1.22.5.0
local-hpc-root: /tmp/foo/.stack-work/install/x86_64-linux/lts-7.4/7.10.3/hpc
local-bin-path: /home/dario/.local/bin
ghc-paths: /home/dario/.stack/programs/x86_64-linux
dario#curie /t/foo> echo $PATH
/home/dario/Applications/bin /home/dario/.rbenv/shims /home/dario/.cabal/bin /home/dario/.nix-profile/bin /home/dario/.nix-profile/sbin /home/dario/.sdkman/candidates/grails/current/bin /usr/local/sbin /usr/local/bin /usr/sbin /usr/bin /sbin /bin /usr/games /usr/local/games /snap/bin /usr/lib/jvm/java-8-oracle/bin /usr/lib/jvm/java-8-oracle/db/bin /usr/lib/jvm/java-8-oracle/jre/bin /home/dario/.local/bin /home/dario/.nix-profile/bin
I rely on the lts determining the version of ghc in use also for CI, so it's a bit worrying if my assumption doesn't hold (anymore?)
(I'm running stack Version 1.2.0 x86_64 hpack-0.14.0)
This is the output of stack setup
dario#curie /t/foo> stack setup
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
I realized that this was due to the faulty way in which I "worked around" this issue:
https://github.com/commercialhaskell/stack/issues/2712
I might open it as another bug report, but it's definitely less important/interesting than fixing #2712
Related
I install GHC on Windows10 using the recommended Haskell Stack. I want to us GHC without all the Stack overhead for Advent of Code. This was working fine until I tried to get the extra package.
I can install it with Stack, but I don't seem to have a way to get it in the global package database. Haskell Stack apparently does not install the cabal executable and seems to have it locked out of their package database.
How do I install the extra package for use with vanilla GHC?
John Miller#DESKTOP-NENAGQH MSYS /d/dev/AdventOfCode2020
$ stack ghc -- AoC/Utils.hs
[1 of 1] Compiling AoC.Utils ( AoC\Utils.hs, AoC\Utils.o )
John Miller#DESKTOP-NENAGQH MSYS /d/dev/AdventOfCode2020
$ ghc AoC/Utils.hs
[1 of 1] Compiling AoC.Utils ( AoC\Utils.hs, AoC\Utils.o ) [Data.List.Extra changed]
AoC\Utils.hs:3:1: error:
Could not find module `Data.List.Extra'
Use -v (or `:set -v` in ghci) to see a list of the files searched for.
|
3 | import Data.List.Extra
| ^^^^^^^^^^^^^^^^^^^^^^
I don't know whether stack supports installing to the global package DB. cabal does though:
$ cabal install --lib extra
Resolving dependencies...
Up to date
$ ghci
GHCi, version 8.10.2: https://www.haskell.org/ghc/ :? for help
Loaded package environment from /home/simon/.ghc/x86_64-linux-8.10.2/environments/default
Prelude> import Data.List.Extra
Prelude Data.List.Extra>
Ok, so stack can install the cabal executable if you beat at it long enough. The package is called cabal-install and it is not in any resolver, but is on Hackage.
stack install cabal-install
Because it is not in the resolver there is a pretty good chance that the version of Cabal, the library for manipulating cabal packages in Haskell, is not compatible. First, ask stack where it keeps its global config
stack path --config-location
Edit that file to allow for the needed dependencies under extra-deps: Stack will helpfully tell you what they are. It may also be helpful to change the resolver to a newer version in that file while your at it.
Now try
stack install cabal-install
again and if these instructions have not fallen out of date since December 2020 you will get the cabal executable somewhere potentially useful.
Before using cabal you will have to run a cabal update to get the package list.
At this point cabal should manipulate your global package database and stack can install GCH and all its libraries over and over and over again if you want to use it for a project instead. They should just keep out of each other's way.
I' reading stack document from https://docs.haskellstack.org/en/stable/GUIDE/
In the section of Different databases, it says that
Databases in stack are layered. For example, the database listing we just gave is called a local database. That is layered on top of a snapshot database, which contains the libraries and executables specified in the snapshot itself. Finally, GHC itself ships with a number of libraries and executables, which forms the global database. To get a quick idea of this, we can look at the output of the stack exec -- ghc-pkg list command in our helloworld project:
/home/michael/.stack/programs/x86_64-linux/ghc-7.10.2/lib/ghc-7.10.2/package.conf.d
Cabal-1.22.4.0
array-0.5.1.0
base-4.8.1.0
bin-package-db-0.0.0.0
binary-0.7.5.0
bytestring-0.10.6.0
containers-0.5.6.2
deepseq-1.4.1.1
directory-1.2.2.0
filepath-1.4.0.0
ghc-7.10.2
ghc-prim-0.4.0.0
haskeline-0.7.2.1
hoopl-3.10.0.2
hpc-0.6.0.2
integer-gmp-1.0.0.0
pretty-1.1.2.0
process-1.2.3.0
rts-1.0
template-haskell-2.10.0.0
terminfo-0.4.0.1
time-1.5.0.1
transformers-0.4.2.0
unix-2.7.1.0
xhtml-3000.2.1
/home/michael/.stack/snapshots/x86_64-linux/nightly-2015-08-26/7.10.2/pkgdb
stm-2.4.4
/home/michael/helloworld/.stack-work/install/x86_64-linux/nightly-2015-08-26/7.10.2/pkgdb
acme-missiles-0.3
helloworld-0.1.0.0
I did the same experiment on windows, but the results are different:
Create a new project by stack new helloworld
Edit helloworld/src/Lib.hs as following
module Lib
( someFunc
) where
import Acme.Missiles
someFunc :: IO ()
someFunc = launchMissiles
Edit helloworld/package.yaml as following
dependencies:
- base >= 4.7 && < 5
- text
- filepath
- containers
- acme-missiles
Since acme-missiles be not in LTS, so I add a extra-deps: in helloworld/stack.yaml
extra-deps:
- acme-missiles-0.3 # not in the LTS
stack build and success, log as following
E:\work-category-theory\helloworld>stack build
Stack has not been tested with GHC versions above 8.6, and using 8.8.3, this may fail
Stack has not been tested with Cabal versions above 2.4, but version 3.0.1.0 was found, this may fail
acme-missiles> configure
acme-missiles> Configuring acme-missiles-0.3...
acme-missiles> build
acme-missiles> Preprocessing library for acme-missiles-0.3..
acme-missiles> Building library for acme-missiles-0.3..
acme-missiles> [1 of 2] Compiling Acme.Missiles
acme-missiles> [2 of 2] Compiling Acme.Missiles.STM
acme-missiles> copy/register
acme-missiles> Installing library in C:\sr\snapshots\c1955c78\lib\x86_64-windows-ghc-8.8.3\acme-missiles-0.3-5Q3zlWTjrQa
Fyz88eRyQT2
acme-missiles> Registering library for acme-missiles-0.3..
Building all executables for `helloworld' once. After a successful build of all of them, only specified executables will
be rebuilt.
helloworld > configure (lib + exe)
Configuring helloworld-0.1.0.0...
helloworld > build (lib + exe)
Preprocessing library for helloworld-0.1.0.0..
Building library for helloworld-0.1.0.0..
[1 of 2] Compiling Lib
[2 of 2] Compiling Paths_helloworld
Preprocessing executable 'helloworld-exe' for helloworld-0.1.0.0..
Building executable 'helloworld-exe' for helloworld-0.1.0.0..
[1 of 2] Compiling Main
[2 of 2] Compiling Paths_helloworld
Linking .stack-work\dist\29cc6475\build\helloworld-exe\helloworld-exe.exe ...
helloworld > copy/register
Installing library in E:\work-category-theory\helloworld\.stack-work\install\5056a8ea\lib\x86_64-windows-ghc-8.8.3\hello
world-0.1.0.0-BBUUJBmDe2RHSTnItHQtB0
Installing executable helloworld-exe in E:\work-category-theory\helloworld\.stack-work\install\5056a8ea\bin
Registering library for helloworld-0.1.0.0..
Completed 2 action(s).
Now call stack exec -- ghc-pkg list
E:\work-category-theory\helloworld>stack exec -- ghc-pkg list
Stack has not been tested with GHC versions above 8.6, and using 8.8.3, this may fail
Stack has not been tested with Cabal versions above 2.4, but version 3.0.1.0 was found, this may fail
C:\Users\Chansey\AppData\Local\Programs\stack\x86_64-windows\ghc-8.8.3\lib\package.conf.d
Cabal-3.0.1.0
Win32-2.6.1.0
array-0.5.4.0
base-4.13.0.0
binary-0.8.7.0
bytestring-0.10.10.0
containers-0.6.2.1
deepseq-1.4.4.0
directory-1.3.6.0
filepath-1.4.2.1
(ghc-8.8.3)
ghc-boot-8.8.3
ghc-boot-th-8.8.3
ghc-compact-0.1.0.0
ghc-heap-8.8.3
ghc-prim-0.5.3
ghci-8.8.3
haskeline-0.7.5.0
hpc-0.6.0.3
integer-gmp-1.0.2.0
libiserv-8.8.3
mtl-2.2.2
parsec-3.1.14.0
pretty-1.1.3.6
process-1.6.8.0
rts-1.0
stm-2.5.0.0
template-haskell-2.15.0.0
text-1.2.4.0
time-1.9.3
transformers-0.5.6.2
xhtml-3000.2.2.1
C:\sr\snapshots\c1955c78\pkgdb
acme-missiles-0.3
E:\work-category-theory\helloworld\.stack-work\install\5056a8ea\pkgdb
helloworld-0.1.0.0
You can see that my outputs are different from the document.
The question is:
Why acme-missiles-0.3 is in C:/sr/snapshots/ rather than /helloworld/.stack-work? (Note that, in windows, C:/sr/ be equivalent to ~/.stack)
Also, in the FAQ of the document from https://docs.haskellstack.org/en/stable/faq/, it mentioned that
Where is stack installed and will it interfere with ghc (etc) I already have installed?
Stack itself is installed in normal system locations based on the mechanism you used (see the Install and upgrade page). Stack installs the Stackage libraries in ~/.stack and any project libraries or extra dependencies in a .stack-work directory within each project's directory. None of this should affect any existing Haskell tools at all.
acme-missiles-0.3 is extra dependencies, why in my experiment, it is in ~/.stack rather than .stack-work directory within project's directory?
Thanks.
How can Haskell be compiled to Javascript using GHCJS and Haskell Stack?
I have the current version of Haksell Stack 1.5.1.
I can initialize a GHCJS project with this command: stack new ghcjsSetup ghcjs
Once in the project directory I try following the Stack documentation for GHCJS.
I create a stack.yaml file and edit it to match the example from the documentation so that is looks like this.
resolver: lts-7.19
compiler: ghcjs-0.2.1.9007019_ghc-8.0.1
compiler-check: match-exact
setup-info:
ghcjs:
source:
ghcjs-0.2.1.9007019_ghc-8.0.1:
url: http://ghcjs.tolysz.org/ghc-8.0-2017-02-05-lts-7.19-9007019.tar.gz
sha1: d2cfc25f9cda32a25a87d9af68891b2186ee52f9
Following the documentation further I try to install and boot GHCJS with this command:
stack setup
This command produces an output which ends with an error.
Preparing to install GHCJS to an isolated location.
This will not interfere with any system-level installation.
Preparing to download ghcjs-0.2.1.9007019_ghc-8.0.1 ...
Already downloaded.
Unpacking GHCJS into /home/u/.stack/programs/x86_64-linux/ghcjs-0.2.1.9007019_ghc-8.0.1/src/ ...
Setting up GHCJS build environment
Installing GHCJS (this will take a long time) ...
ghcjs-0.2.1.9007019: configure (lib + exe)
Package ghcjs uses a custom Cabal build, but does not use a custom-setup stanza
Using the explicit setup deps approach based on configuration
Strongly recommend fixing the package's cabal file
[1 of 2] Compiling Main ( /home/u/.stack/programs/x86_64-linux/ghcjs-0.2.1.9007019_ghc-8.0.1/src/Setup.hs, /home/u/.stack/programs/x86_64-linux/ghcjs-0.2.1.9007019_ghc-8.0.1/src/.stack-work/dist/x86_64-linux/Cabal-1.24.0.0/setup/Main.o )
[2 of 2] Compiling StackSetupShim ( /home/u/.stack/setup-exe-src/setup-shim-mPHDZzAJ.hs, /home/u/.stack/programs/x86_64-linux/ghcjs-0.2.1.9007019_ghc-8.0.1/src/.stack-work/dist/x86_64-linux/Cabal-1.24.0.0/setup/StackSetupShim.o )
Linking /home/u/.stack/programs/x86_64-linux/ghcjs-0.2.1.9007019_ghc-8.0.1/src/.stack-work/dist/x86_64-linux/Cabal-1.24.0.0/setup/setup ...
Configuring ghcjs-0.2.1.9007019...
ghcjs-0.2.1.9007019: build (lib + exe)
Preprocessing library ghcjs-0.2.1.9007019...
/home/u/.stack/programs/x86_64-linux/ghcjs-0.2.1.9007019_ghc-8.0.1/src/src/Compiler/JMacro/Base.hs:1:55: warning:
-XOverlappingInstances is deprecated: instead use per-instance pragmas OVERLAPPING/OVERLAPPABLE/OVERLAPS
/home/u/.stack/programs/x86_64-linux/ghcjs-0.2.1.9007019_ghc-8.0.1/src/src/Compiler/JMacro/QQ.hs:1:55: warning:
-XOverlappingInstances is deprecated: instead use per-instance pragmas OVERLAPPING/OVERLAPPABLE/OVERLAPS
[ 1 of 50] Compiling GHCJS.Prim.TH.Serialized ( lib/ghcjs-prim/GHCJS/Prim/TH/Serialized.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/GHCJS/Prim/TH/Serialized.o )
Because it is too long to post here I have excluded the middle of the output. Which includes lots of warning messages.
[49 of 50] Compiling Compiler.Program ( src/Compiler/Program.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Compiler/Program.o )
[50 of 50] Compiling GHCJS ( src/GHCJS.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/GHCJS.o )
Preprocessing executable 'ghcjs' for ghcjs-0.2.1.9007019...
[1 of 1] Compiling Main ( src-bin/Main.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/ghcjs/ghcjs-tmp/Main.o )
Linking .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/ghcjs/ghcjs ...
Preprocessing executable 'ghcjs-boot' for ghcjs-0.2.1.9007019...
[1 of 1] Compiling Main ( src-bin/Boot.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/ghcjs-boot/ghcjs-boot-tmp/Main.o )
/home/u/.stack/programs/x86_64-linux/ghcjs-0.2.1.9007019_ghc-8.0.1/src/src-bin/Boot.hs:690:1: warning: [-Wtabs]
Tab character found here, and in three further locations.
Please use spaces instead.
Linking .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/ghcjs-boot/ghcjs-boot ...
Preprocessing executable 'ghcjs-pkg' for ghcjs-0.2.1.9007019...
[1 of 1] Compiling Main ( src-bin/Pkg.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/ghcjs-pkg/ghcjs-pkg-tmp/Main.o )
Linking .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/ghcjs-pkg/ghcjs-pkg ...
/usr/bin/ld: cannot find -ltinfo
collect2: error: ld returned 1 exit status
`gcc' failed in phase `Linker'. (Exit code: 1)
-- While building package ghcjs-0.2.1.9007019 using:
/home/u/.stack/programs/x86_64-linux/ghcjs-0.2.1.9007019_ghc-8.0.1/src/.stack-work/dist/x86_64-linux/Cabal-1.24.0.0/setup/setup --builddir=.stack-work/dist/x86_64-linux/Cabal-1.24.0.0 build lib:ghcjs exe:ghcjs exe:ghcjs-boot exe:ghcjs-pkg exe:ghcjs-run exe:haddock-ghcjs exe:hsc2hs-ghcjs --ghc-options " -ddump-hi -ddump-to-file"
Process exited with code: ExitFailure 1
"Linking .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/ghcjs-pkg/ghcjs-pkg ...
/usr/bin/ld: cannot find -ltinfo"
You are missing the libtinfo library which is part of ncurses. Depending on your environment try something like:
sudo apt-get install libtinfo-dev
As an aside, getting all the pieces that ghcjs needs to build successfully is tricky and not well documented as of September 2018. One might hope that as the project matures it will get easier to install, and that a binary package will be produced. Know that you are not the only person who has these issues. It takes some patience and trial-and-error to get ghcjs working right now.
Others have had success using nix, I did not.
I am getting a GHCI segfault when trying to create a database connection in GHCI with postgresql-simple.
I am using GHC 8.0.1, OSX 10.11.16. I do not have a system GHC, only the one installed by stack.
If I do the following in my project, it segfaults:
$ stack ghci
Loaded GHCi configuration from /private/var/folders/wb/vvtxjd7n2qz02f571yjyr9j40000gs/T/ghci62972/ghci-script
gchi> :set -XOverloadedStrings
gchi> import Database.PostgreSQL.Simple
gchi> let connstr = "host=localhost port=5432 user=myusername password=mypass dbname=local"
gchi> conn <- connectPostgreSQL connstr
zsh: segmentation fault stack ghci
I thought it might be worth looking at that file it mentions, so here are the contents:
> cat /private/var/folders/wb/vvtxjd7n2qz02f571yjyr9j40000gs/T/ghci62972/ghci-script
:load "/Users/erewok/projects/haskell/simpleservantblog/app/Main.hs" "Api" "Api.Post" "Api.User" "Config" "Html.Home" "Models.Author" "Models.Post"
:module + Api Api.Post Api.User Config Html.Home Models.Author Models.Post
It's a list of all the modules loaded from the project (which compiles and runs fine).
Here's the complete output of everything from starting ghci up to the seg fault:
$ stack ghci
The following GHC options are incompatible with GHCi and have not been passed to it: -threaded
Using main module: 1. Package `simpleservantblog' component exe:simpleservantblog-exe with main-is file: /Users/erewok/projects/haskell/simpleservantblog/app/Main.hs
Configuring GHCi with the following packages: simpleservantblog
GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /Users/erewok/.ghci
[1 of 8] Compiling Models.Author ( /Users/erewok/projects/haskell/simpleservantblog/src/Models/Author.hs, interpreted )
[2 of 8] Compiling Models.Post ( /Users/erewok/projects/haskell/simpleservantblog/src/Models/Post.hs, interpreted )
[3 of 8] Compiling Html.Home ( /Users/erewok/projects/haskell/simpleservantblog/src/Html/Home.hs, interpreted )
[4 of 8] Compiling Api.User ( /Users/erewok/projects/haskell/simpleservantblog/src/Api/User.hs, interpreted )
[5 of 8] Compiling Api.Post ( /Users/erewok/projects/haskell/simpleservantblog/src/Api/Post.hs, interpreted )
[6 of 8] Compiling Config ( /Users/erewok/projects/haskell/simpleservantblog/src/Config.hs, interpreted )
[7 of 8] Compiling Api ( /Users/erewok/projects/haskell/simpleservantblog/src/Api.hs, interpreted )
[8 of 8] Compiling Main ( /Users/erewok/projects/haskell/simpleservantblog/app/Main.hs, interpreted )
Ok, modules loaded: Api, Config, Api.Post, Api.User, Html.Home, Models.Post, Models.Author, Main.
Loaded GHCi configuration from /private/var/folders/wb/vvtxjd7n2qz02f571yjyr9j40000gs/T/ghci64266/ghci-script
gchi> :set -XOverloadedStrings
gchi> import Database.PostgreSQL.Simple
gchi> let connstr = "host=localhost port=5432 user=myusername password=mypass dbname=local"
gchi> conn <- connectPostgreSQL connstr
zsh: segmentation fault stack ghci
More Information
Postgresql Version: 9.5, installed using the EnterpriseDB installer
The request to post my stack.yaml (which is below) reminded me of an issue I had when trying to install postgresql-libpq. This is probably related.
Stack.yaml
# This file was automatically generated by stack init
# For more information, see: http://docs.haskellstack.org/en/stable/yaml_configuration/
# Specifies the GHC version and set of packages available (e.g., lts-3.5, nightly-2015-09-21, ghc-7.10.2)
resolver: nightly-2016-08-25
# Local packages, usually specified by relative directory name
packages:
- '.'
- location:
git: https://www.github.com/mattjbray/elm-export
commit: 8868c1f09597f44c2e18e014cd9fbcf8320c3fea
extra-dep: True
- location:
git: https://www.github.com/mattjbray/servant-elm
commit: e13c8def8127ea339e9801d804638854947193e8
extra-dep: True
# Packages to be pulled from upstream that are not in the resolver (e.g., acme-missiles-0.3)
extra-deps:
- wai-make-assets-0.1.1
# Override default flag values for local packages and extra-deps
flags: {}
# Extra package databases containing global packages
extra-package-dbs: []
# Control whether we use the GHC we find on the path
# system-ghc: true
# Extra directories used by stack for building
# extra-include-dirs: [/path/to/dir]
extra-lib-dirs: [/usr/local/opt/libiconv/lib, /usr/local/lib, /usr/lib]
Also segfaults on GHC 7.10.3 with resolver lts-6.17
gchi> conn <- connectPostgreSQL connstr
zsh: segmentation fault stack ghci --resolver lts-6.17
An Idea I had
I think the version of postgresql-libpq I am using was built with libiconv.2.dylib compiled for Postgresql 9.4, but the database I am trying to connect to is actually Postgresql 9.5. This may be the reason for my issue.
A Thing I Did Inspired By that Idea
Here are some steps I took to try to debug further and/or fix this. I first linked the Postgresql 9.5 *dylib files into my /usr/local/lib directory in order to replace the old ones linked against the Postgresql 9.4 version.
$ cd /usr/local/lib
$ sudo ln -s -f /Library/PostgreSQL/9.5/lib/*dylib .
After that, I tried to force stack to rebuild postgresql-libpq and postgresql-simple in this way:
$ stack exec -- ghc-pkg unregister --force postgresql-simple
$ stack exec -- ghc-pkg unregister --force postgresql-libpq
$ rm -rf ~/.stack/precompiled/x86_64-osx/ghc-8.0.1/1.24.0.0/postgresql-libpq-0.9.1.1/
$ rm -rf ~/.stack/precompiled/x86_64-osx/ghc-8.0.1/1.24.0.0/postgresql-simple-0.5.2.*
$ stack build
At which point, it promised me it would build and configure the removed packages. Still segfaulted when I ran the above, however.
While attempting to generate a stack trace for my issue, I discovered that I can start ghci in the following way:
$ stack ghci --ghci-options -fexternal-interpreter
And then, for whatever, reason, the segfault does not appear and everything works as expected. I have no idea if anyone else will find this useful.
The thing that seemed weird to me was that I didn't have an issue when the code was compiled and run. I only had an issue in GHCI.
Anyway, until I find out more or someone has a better suggestion, I'll go with this so I can continue testing what I want in the REPL.
I have some cabal failures after scaffolding my haskell project using the holy-project.
I don't think the issue is related to that plugin (seems more like general cabal question) because I could reproduce it starting from a standard cabal init. I'd be surprised if the issue is related to SublimeHaskell either as many people seem to be using it.
Here is the cabal file that was generated (I simplified/shortened it a bit):
(the holy-project generates some example source files along)
name: test-holy
version: 0.1.0.0
build-type: Simple
cabal-version: >=1.10
library
exposed-modules: TestHoly
, TestHoly.Swallow
, TestHoly.Coconut
build-depends: base >=4.7 && <4.8
ghc-options: -Wall
hs-source-dirs: src
default-language: Haskell2010
cabal build works
The following command does not work:
$ cabal clean && cabal configure && cabal build --ghc-options="-fforce-recomp -Wall -fno-code"
cleaning...
Resolving dependencies...
Configuring test-non-holy2-0.1.0.0...
Building test-non-holy2-0.1.0.0...
Preprocessing library test-non-holy2-0.1.0.0...
[1 of 3] Compiling TestHoly.Coconut ( src/TestHoly/Coconut.hs, nothing )
[2 of 3] Compiling TestHoly.Swallow ( src/TestHoly/Swallow.hs, nothing )
[3 of 3] Compiling TestHoly ( src/TestHoly.hs, nothing )
[1 of 3] Compiling TestHoly.Coconut ( src/TestHoly/Coconut.hs, nothing )
[2 of 3] Compiling TestHoly.Swallow ( src/TestHoly/Swallow.hs, nothing )
[3 of 3] Compiling TestHoly ( src/TestHoly.hs, nothing )
ar: dist/build/TestHoly.o: No such file or directory
ar: dist/build/TestHoly/Swallow.o: No such file or directory
ar: dist/build/TestHoly/Coconut.o: No such file or directory
From what I understand, due to the -fno-code flag (Omit code generation) no object files are generated hence the linker fails. Is that expected? Or should the linker not have been called?
Why am I running that cabal command?
As I said earlier on: I'm using SublimeText to edit my project. It fails on the project-holy generated cabal file with the following message:
Build FAILED
REMAINING STDERR:
Warning: the following files would be used as linker inputs, but linking is not being done: dist/build/TestHoly.dyn_o dist/build/TestHoly/Swallow.dyn_o dist/build/TestHoly/Coconut.dyn_o
ghc: no input files
Usage: For basic information, try the `--help' option.
Through the discussion on SublimeHaskell#158 I followed the suggestion by nh2 to run this cabal command directly (because it's the one used by SublimeHaskell).
I'd appreciate if someone can shed a light on this!
Version info
$ cabal --version
cabal-install version 1.18.0.5
using version 1.18.1.4 of the Cabal library
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.8.3
$ system_profiler SPSoftwareDataType
Software:
System Software Overview:
System Version: OS X 10.10 (14A389)
Kernel Version: Darwin 14.0.0
This is a known issue in cabal.
See https://github.com/haskell/cabal/issues/1176
If you don't pass -fforce-recomp you might be ok for incremental checking and only hit the error when you needed to do a clean build.
But absent that, cabal just doesn't know what to do when ghc doesn't actually compile things...