I asked this on haskell-cafe, but there are no responses yet so maybe not enough people are using 7.8. Perhaps more people are reading stack overflow nowadays:
I recently upgraded to 7.8.2 and I have a silly question. How do you
get ghci to load compiled modules? When I try this:
% cat >T.hs
module T where
x :: Int
x = 42
% ghc -c -dynamic-too T.hs
% s
T.dyn_hi T.dyn_o T.hi T.hs T.o
% ghci
GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package filepath-1.3.0.2 ... linking ... done.
Prelude> :l T
[1 of 1] Compiling T ( T.hs, interpreted )
Ok, modules loaded: T.
*T>
It still loads the file interpreted, even though there is a .dyn_o
present. What am I doing wrong?
This is on x86-64 OS X.
There is one other thing which may be related. Since I load everything interpreted now, I've noticed that the input gets very laggy when I have a hundred or so modules loaded. Also the haskeline state gets confused, e.g. I hit escape k to get the previous line, but then it spontaneously goes back into insert mode again. It stays balky and awkward for about 15 seconds before returning to normal slightly. It's almost as if, after loading all the bytecode, it's still doing tons of work in the background, with constant GC freezes. But what work could it be doing? The bytecode is loaded and I haven't asked it to do anything yet! I don't know if this is new to 7.8, or if it's a result of loading bytecode instead of binary.
Turns out this is a known ghc bug:
https://ghc.haskell.org/trac/ghc/ticket/8736
The fix is to compile with -dynamic, not -dynamic-too.
Related
I made FFI bindings to C++ unordered_map(a.k.a. hash_map) container and its wrapper library called libstl.a.
At the first time, it used to work well. But after some point, it has failed to link the library with the following error messages and I can't figure out why.
$ ghci -L. -lstl -lstdc++
GHCi, version 7.6.2: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading object (static archive) ./libstl.a ... done
Loading object (dynamic) /usr/lib/gcc/x86_64-linux-gnu/4.7/libstdc++.so ... done
final link ... ghc: ./libstl.a: unknown symbol `_ZZNKSt8__detail20_Prime_rehash_policy11_M_next_bktEmE10__fast_bkt'
linking extra libraries/objects failed
Source codes for the library is located in https://github.com/comatose/stl-container.
Any help will be appreciated.
I've had similar problems loading .o files into ghci. From what I understand, the problem is that g++ leaves 'weak symbols' in .o files, and ghci doesn't deal with them very well.
I found a thread about it with a helpful follow-up:
http://www.haskell.org/pipermail/haskell-cafe/2012-March/099926.html
in which the suggested solution is to put everything compiled by g++ into shared libraries (.so files instead of .a), and that seems to clear up the weak symbol problem. Shared libraries can be a bit of a pain. I suggest that you look at libtool. It's a helper program that can handle a lot of the complications:
http://www.gnu.org/software/libtool/
I am having some issues using HsLua as a library. Lua compiles just fine as a standalone. And this version runs on my Linux box without a problem. Here is the linking error I see.
GHCi, version 7.4.1: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> import Scripting.Lua as Lua
Prelude Lua> l <- Lua.newstate
Loading package hslua-0.3.4 ... linking ... <interactive>: C:\..\AppData\Roaming\cabal\hslua-0.3.4\ghc-7.4.1\HShslua-0.3.4.o: unknown symbol `___strtod'
ghc.exe: unable to load package `hslua-0.3.4'
Prelude Lua>
I did some poking around the libraries and found the call for strtod and I think I may have been close but obviously not close enough.
EDIT
This may or may not help. I'll post the cabal file, I made a couple of changes such as adding the os(windows) portion.
Name: hslua
Version: 0.3.4
...
Extra-source-files: src/*.h
Library
Build-depends: base==4.*
Exposed-modules: Scripting.Lua, Scripting.Lua.ConfigFile
Hs-source-dirs: src
C-sources: src/lapi.c, src/lauxlib.c, src/lbaselib.c, src/lcode.c,
src/ldblib.c, src/ldebug.c, src/ldo.c, src/ldump.c, src/lfunc.c,
src/lgc.c, src/linit.c, src/liolib.c, src/llex.c, src/lmathlib.c,
src/lmem.c, src/loadlib.c, src/lobject.c, src/lopcodes.c,
src/loslib.c, src/lparser.c, src/lstate.c, src/lstring.c,
src/lstrlib.c, src/ltable.c, src/ltablib.c, src/ltm.c,
src/lundump.c, src/lvm.c, src/lzio.c, src/ntrljmp.c
Include-dirs: src
ghc-options: -Wall
extensions: ForeignFunctionInterface
if os(linux)
CC-Options: "-DLUA_USE_LINUX"
if os(darwin)
CC-Options: "-DLUA_USE_MACOSX"
if os(freebsd)
CC-Options: "-DLUA_USE_POSIX"
if os(windows)
CC-Options: "-DLUA_BUILD_AS_DLL"
includes: stdlib.h
I tried a couple of different ways to get the stdlib in the project, I've added it in main headers for the project and I've also specified it in the cabal file. Makes me think that is barking up the wrong tree.
EDIT-2
Well I haven't been able to get this built yet on win32. A couple of other things I tried to do that didn't work for me just in case someone else runs into the same problem.
I linked all of the built object files into a static archive and I got the same error as above. I also tried to use a build DLL and I got a different error but I'm not sure if it were progress forwards or backwards.
C:\..\hslua-0.3.4>ghci liblua.dll -package hslua
GHCi, version 7.4.1: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package hslua-0.3.4 ... linking ... ghc.exe: C:\..\hslua-0.3.4\ghc-7.4.1\HShslua-0.3.4.o: unknown symbol `_lua_close'
ghc.exe: unable to load package `hslua-0.3.4'
Hey I was struggling with exactly the same thing on windows and what worked for me was adding the following to the cabal file
if os(windows)
CC-options: "-D__NO_ISOCEXT"
that makes gcc not use the special __strtod but rather just the normal one.
I have a trivial Template Haskell program that prints the name of the current module (Main, here):
{-# LANGUAGE TemplateHaskell #-}
module Main
( main
) where
import Language.Haskell.TH
import Language.Haskell.TH.Syntax
modName ∷ String
modName = $(fmap loc_module qLocation »= λmod → return (LitE (StringL mod) ))
main ∷ IO ()
main = putStrLn modName
When I compile this, I get the following Loading messages from ghc:
tsuraan#localhost ~/test/modname $ ghc --make Main
[1 of 1] Compiling Main ( Main.hs, Main.o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package array-0.4.0.0 ... linking ... done.
Loading package deepseq-1.3.0.0 ... linking ... done.
Loading package containers-0.4.2.1 ... linking ... done.
Loading package pretty-1.1.1.0 ... linking ... done.
Loading package template-haskell ... linking ... done.
Linking Main ...
Why does ghc load all these packages when Template Haskell is enabled? Whenever I build a program that uses Template Haskell, especially one that is built against a lot of packages, my compile warnings are overwhelmed with these superfluous "Loading" messages. It would be nice if I could stop the messages from being printed, or stop the (unnecessary?) module loading from happening at all.
Template Haskell runs at compile time, via a bytecode interpreter (GHCi). Any package dependencies that you have -- at compile time -- will be loaded dynamically into GHC -- at compile time, so that you can execute your splices.
One of your dependencies is the Template Haskell library itself, which in turn depends on most of the core things.
You can prevent the "Loading package" lines from being printed by passing the -v0 flag to GHC. (This also suppresses the "Compiling" and "Linking" lines, but warnings and errors are still shown.)
I have a source file that will only compile with Cabal. It's test code, and in the past (before I complicated my Haskell environment) I would run functions from within ghci.
I know ghci can use object files to load code, but when I try to do so I get the following error. So what am I missing?
[mlitchard#Boris Boris_Test]$ ghci /home/mlitchard/Boris_Test/dist/build/Boris_Test/Boris_Test-tmp/Main.o
GHCi, version 7.4.1: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading object (static) /home/mlitchard/Boris_Test/dist/build/Boris_Test/Boris_Test-tmp/Main.o ... done
final link ... ghc: /home/mlitchard/Boris_Test/dist/build/Boris_Test/Boris_Test-tmp/Main.o: unknown symbol
monadzmcontrolzm0zi3zi1zi3_ControlziMonadziTransziControl_zdfMonadBaseControlIOIO_closure'
linking extra libraries/objects failed
When you specify object files manually, GHCi can't tell what the object file depends on, which it would be able to do with .hs files, because it has access to the import ... lines in that situation.
Therefore, you need to add the object files of all the relevant dependencies manually, in this case by adding -package monad-control, when invoking GHCi.
Ok, I've been using the -i compile option to specify the folder to some haskell source when I compile using GHC.
ghc -threaded -i/d/haskell/src --make xxx.hs
I understand it uses those files as 'libraries' while compiling but can i do same in GHCi?
I usually import haskell prepackaged lib e.g. import Data.List or :m +Data.List.
I tried import /d/haskell/src -- does not work!
EDIT
From Haskell doc: Chapter 2 Using GHCi
Note that in GHCi, and ––make mode, the -i option is used to specify the search path for source files, whereas in standard batch-compilation mode the -i option is used to specify the search path for interface files.
The '-i' flag is fine, the problem is with loading the module.
Within ghci, :m will only switch to either pre-compiled modules, or modules which were specified on the command-line. You need to use :add MyModule to tell ghci to compile a Haskell source file.
If you have
./src/Module/SubModule.hs
you can load it with the following:
localuser$ ghci -isrc
GHCi, version 7.0.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
Prelude> :add Module.SubModule
[1 of 1] Compiling Module.SubModule ( src/Module/SubModule.hs, interpreted )
Ok, modules loaded: Module.SubModule.
*Module.SubModule>
I think you can say :set -i /d/haskell/src; many, but not all, GHC options can be set that way. Alternatively, you should be able to use it as a parameter directly: ghci -i /d/haskell/src.