Compiling Haskell to JavaScript using GHCJS and Haskell Stack - haskell

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.

Related

Unable to understand "Different databases" section in stack document

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.

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

GUI programming in Haskell - installation problems on Ubuntu

is there a GUI package that is still up-to-date?
I tried installing both wxHaskell and gtk2hs today and both fail on dependencies I just cannot solve (wxHaskell cannot find some wxWidget libs and while trying the glade tutorial gtk2hs fails on a missing pkg-config libglade2-0 I installed too).
I guess it's just some problem with me not understanding the linux/cabal/package install things good enough but is there a up-to-date tutorial how to get started (install) some GUI lib for Haskell somewhere around?
Here are the errors:
carsten#Carsten-VirtualBox:~$ cabal install glade
Resolving dependencies...
[1 of 2] Compiling SetupWrapper ( /tmp/glade-0.12.1-12934/glade-0.12.1/SetupWrapper.hs, /tmp/glade-0.12.1-12934/glade-0.12.1/dist/setup/SetupWrapper.o )
[2 of 2] Compiling Main ( /tmp/glade-0.12.1-12934/glade-0.12.1/Setup.hs, /tmp/glade-0.12.1-12934/glade-0.12.1/dist/setup/Main.o )
Linking /tmp/glade-0.12.1-12934/glade-0.12.1/dist/setup/setup ...
[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 ...
Configuring glade-0.12.1...
setup: The pkg-config package libglade-2.0 version >=2.0.0 is required but it
could not be found.
cabal: Error: some packages failed to install:
glade-0.12.1 failed during the configure step. The exception was:
ExitFailure 1
and
carsten#Carsten-VirtualBox:~$ cabal install wxc
Resolving dependencies...
[1 of 1] Compiling Main ( /tmp/wxc-0.90.0.4-13078/wxc-0.90.0.4/Setup.hs, /tmp/wxc-0.90.0.4-13078/wxc-0.90.0.4/dist/setup/Main.o )
Linking /tmp/wxc-0.90.0.4-13078/wxc-0.90.0.4/dist/setup/setup ...
Configuring wxc-0.90.0.4...
Warning: No config found to match: /usr/bin/wx-config --version=2.9 --version-full
in /usr/lib/x86_64-linux-gnu/wx/config
If you require this configuration, please install the desired
library build. If this is part of an automated configuration
test and no other errors occur, you may safely ignore it.
You may use wx-config --list to see all configs available in
the default prefix.
setup: failed
cabal: Error: some packages failed to install:
wxc-0.90.0.4 failed during the configure step. The exception was:
ExitFailure 1
This is really frustrating me - maybe someone can help me here - thank you!
I am running 12.04 and everything works fine for me.
Are you sure you have libglade2-dev installed ? That should fix it.
Coming from ArchLinux i had the same problem at first when i didn't know there were separate dev libraries, i don't remember having to do this in arch.

Resources