Unable to understand "Different databases" section in stack document - haskell

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.

Related

Compiling Haskell to JavaScript using GHCJS and Haskell Stack

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.

Building project dependent on gtk2hs fails on lts-7.8 and later

Building project dependent on glib fails on lts-7.8 and later after Cabal becomes 1.24.1.0.
Steps to reproduce
Add glib to a project's .cabal file
build-depends: base
, gtktest
, glib
Run following commands
stack install gtk2hs-buildtools
stack build
Result
The following error occurred
...
[debug] Ignoring package Cabal due to wanting version 1.24.1.0 instead of 1.24.0.0
#(Stack\Build\Installed.hs:196:5)
...
-- While building package glib-0.13.4.1 using:
C:\Users\foo\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.1\bin\ghc.EXE --make -odir C:\Users\foo\AppData\Local\Temp\stack5512\glib-0.13.4.1\.stack-work\dist\b7fec021\setup -hidir C:\Users\foo\AppData\Local\Temp\stack5512\glib-0.13.4.1\.stack-work\dist\b7fec021\setup -i -i. -package=Cabal-1.24.0.0 -clear-package-db -global-package-db -package-db=C:\sr\snapshots\a78c6a89\pkgdb C:\Users\foo\AppData\Local\Temp\stack5512\glib-0.13.4.1\Setup.hs -o C:\Users\foo\AppData\Local\Temp\stack5512\glib-0.13.4.1\.stack-work\dist\b7fec021\setup\setup
Process exited with code: ExitFailure 1
Logs have been written to: C:\Users\foo\Documents\Files\Haskell\gtktest\.stack-work\logs\glib-0.13.4.1.log
[1 of 1] Compiling Main ( C:\Users\foo\AppData\Local\Temp\stack5512\glib-0.13.4.1\Setup.hs, C:\Users\foo\AppData\Local\Temp\stack5512\glib-0.13.4.1\.stack-work\dist\b7fec021\setup\Main.o )
C:\Users\foo\AppData\Local\Temp\stack5512\glib-0.13.4.1\Setup.hs:8:29: error:
Couldn't match expected type ‘Distribution.Simple.UserHooks.UserHooks’
with actual type ‘Cabal-1.24.1.0:Distribution.Simple.UserHooks.UserHooks’
NB: Cabal-1.24.1.0:Distribution.Simple.UserHooks.UserHooks’
is defined in ‘Distribution.Simple.UserHooks’
in package ‘Cabal-1.24.1.0’
‘Distribution.Simple.UserHooks.UserHooks’
is defined in ‘Distribution.Simple.UserHooks’
in package ‘Cabal-1.24.0.0’
In the first argument of ‘defaultMainWithHooks’, namely
gtk2hsUserHooks’
In the expression: defaultMainWithHooks gtk2hsUserHooks
In an equation for ‘main’:
main = defaultMainWithHooks gtk2hsUserHooks
I thought that Cabal-1.24.0.0 in the ghc-8.0.1 global package was causing problems, and succeeded building it after installing Cabal-1.24.1.0 in ghc 's global package.
However, this method is difficult for beginners and I do not think the right solution. How is the correct way to solve it?
Stack version
Version 1.2.0, Git revision 123819b7d65df2ad7fe63fb5eb39a98536acb5f3 (4055 commits) x86_64 hpack-0.14.0

Why does Stack pick ghc 7.10 even with an lts for ghc8?

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

How can I fix wrong .cabal file of dependent package in Haskell Stack?

I use Haskell Stack in Windows 10
When I try to install gtk as dependency of my own package, I got following messages.
glib-0.13.2.2: configure
glib-0.13.2.2: build
Progress: 1/5
-- While building package glib-0.13.2.2 using:
C:\Users\junyoung\AppData\Local\Temp\stack6012\glib-0.13.2.2\.stack-work\dist\2672c1f3\setup\setup --builddir=.stack-work\dist\2672c1f3 build --ghc-options " -ddump-hi -ddump-to-file"
Process exited with code: ExitFailure 1
Logs have been written to: C:\Users\junyoung\Documents\HaskellProject\StackProject\Hotepad\.stack-work\logs\glib-0.13.2.2.log
[1 of 2] Compiling SetupWrapper ( SetupWrapper.hs, C:\Users\junyoung\AppData\Local\Temp\stack6012\glib-0.13.2.2\.stack-work\dist\2672c1f3\setup\SetupWrapper.o )
[2 of 2] Compiling Main ( C:\Users\junyoung\AppData\Local\Temp\stack6012\glib-0.13.2.2\Setup.hs, C:\Users\junyoung\AppData\Local\Temp\stack6012\glib-0.13.2.2\.stack-work\dist\2672c1f3\setup\Main.o )
Linking C:\Users\junyoung\AppData\Local\Temp\stack6012\glib-0.13.2.2\.stack-work\dist\2672c1f3\setup\setup.exe ...
[1 of 2] Compiling Gtk2HsSetup ( Gtk2HsSetup.hs, dist\setup-wrapper\Gtk2HsSetup.o )
[2 of 2] Compiling Main ( SetupMain.hs, dist\setup-wrapper\Main.o )
Linking dist/setup-wrapper\setup.exe ...
Configuring glib-0.13.2.2...
Building glib-0.13.2.2...
Preprocessing library glib-0.13.2.2...
.stack-work\dist\2672c1f3\build\System\Glib\StoreValue_hsc_utils.o:StoreValue_hsc_utils.c:(.text+0x0): multiple definition of `__debugbreak'
.stack-work\dist\2672c1f3\build\System\Glib\StoreValue_hsc_make.o:StoreValue_hsc_make.c:(.text+0x0): first defined here
collect2.exe: error: ld returned 1 exit status
linking .stack-work\dist\2672c1f3\build\System\Glib\StoreValue_hsc_make.o failed (exit code 1)
command was: C:\Users\junyoung\AppData\Local\Programs\stack\x86_64-windows\ghc-7.10.3\mingw\bin\gcc.exe .stack-work\dist\2672c1f3\build\System\Glib\StoreValue_hsc_make.o .stack-work\dist\2672c1f3\build\System\Glib\StoreValue_hsc_utils.o -o .stack-work\dist\2672c1f3\build\System\Glib\StoreValue_hsc_make.exe -LC:\Users\junyoung\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\lib -LC:/msys64/mingw64/lib -lgobject-2.0 -lglib-2.0 -lintl -LC:\Users\junyoung\AppData\Roaming\stack\snapshots\f21484d8\lib\x86_64-windows-ghc-7.10.3\utf8-string-1.0.1.1-L8eKHa7Iv9q7FVKUYW6u4b -LC:\Users\junyoung\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\lib -LC:\Users\junyoung\AppData\Roaming\stack\snapshots\64a043b0\lib\x86_64-windows-ghc-7.10.3\text-1.2.2.1-HmqVQnZSpjaC156ABqPhne -LC:\Users\junyoung\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\lib -LC:\Users\junyoung\AppData\Local\Programs\stack\x86_64-windows\ghc-7.10.3\lib\binar_3uXFWMoAGBg0xKP9MHKRwi -LC:\Users\junyoung\AppData\Local\Programs\stack\x86_64-windows\ghc-7.10.3\lib\conta_2C3ZI8RgPO2LBMidXKTvIU -LC:\Users\junyoung\AppData\Local\Programs\stack\x86_64-windows\ghc-7.10.3\lib\bytes_6VWy06pWzJq9evDvK2d4w6 -LC:\Users\junyoung\AppData\Local\Programs\stack\x86_64-windows\ghc-7.10.3\lib\deeps_6vMKxt5sPFR0XsbRWvvq59 -LC:\Users\junyoung\AppData\Local\Programs\stack\x86_64-windows\ghc-7.10.3\lib\array_67iodizgJQIIxYVTp4emlA -LC:\Users\junyoung\AppData\Local\Programs\stack\x86_64-windows\ghc-7.10.3\lib\base_HQfYBxpPvuw8OunzQu6JGM -lwsock32 -luser32 -lshell32 -LC:\Users\junyoung\AppData\Local\Programs\stack\x86_64-windows\ghc-7.10.3\lib\integ_2aU3IZNMF9a7mQ0OzsZ0dS -LC:\Users\junyoung\AppData\Local\Programs\stack\x86_64-windows\ghc-7.10.3\lib\ghcpr_8TmvWUcS1U1IKHT0levwg3 -LC:\Users\junyoung\AppData\Local\Programs\stack\x86_64-windows\ghc-7.10.3\lib/rts -lm -lwsock32 -lgdi32 -lwinmm
I found that this messages is because of glib.cabal files bug at glib-0.13.2.2, so when I try to install glib separately, I edit glib.cabal (remove -D___attribute__(A)= option on cpp) and install clearly.
However, when I try to install it using stack, stack install gtk command always takes Hackage one instead of installed glib package.
For short, therefore, my question is, how can I using separately installed glib? Or, is there any way to modify packages .cabal file while installing it, using options or whatever?
Stack lets you use a dependency from a local directory, or a github repo. So feel free to fork the project, do the fixes, maybe even do a PR, and then put this into your stack.yaml under "packages" section:
- location:
git: https://github.com/user/repo
commit: a1b3559090e9c75ce1d46969085fe4f918b2fa82

cabal build --ghc-options="-fforce-recomp -Wall -fno-code" fails

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...

Resources