This is an embarrassingly simple problem, but its solution yet eludes me. As the title indicates, I simply want to specify to GHC the location of all my source files. This should be simple; the GHC user guide:
-idirs
This flag appends a colon-separated
list of dirs to the search path.
So, I tried the following invocations:
ghc -isrc/ -v -outputdir build/ --make -Wall Main.hs
ghc -isrc/: -v -outputdir build/ --make -Wall Main.hs
ghc -i:src/: -v -outputdir build/ --make -Wall Main.hs
ghc -i"src/" -v -outputdir build/ --make -Wall Main.hs
ghc -i"src/": -v -outputdir build/ --make -Wall Main.hs
ghc -i:"src/": -v -outputdir build/ --make -Wall Main.hs
On every invocation GHC gave the error: "<no location info>: can't find file: Main.hs"
As you probably could have guessed, Main.hs is located in a subdirectory from the working directory called "src". Just in case it matters, I'm on Windows XP, and I'm using GHC 6.12.2. I'm assuming there is some small problem that I'm just missing.
-i specifies where GHC will search for other source files, other than the ones you specify on the command line. So your Main.hs there will also need a src/ prefix. E.g.
$ ghc -isrc src/Main.hs --make
[1 of 1] Compiling Main ( src/Main.hs, src/Main.o )
Linking src/Main ...
Alternatively, you could use cabal, and have cabal init generate all the build metadata for you.
Related
Long story short: I have two .hs files, where Main.hs uses module Lib.hs
When I try to compile them as suggested by the book Real World Haskell, p 115, I got problems:
$ ghc -c Lib.hs
$ ghc -o main Main.hs Lib.o
[2 of 2] Compiling Main ( Main.hs, Main.o )
Linking main ...
duplicate symbol '_Lib_add1_info' in:
./Lib.o
Lib.o
duplicate symbol '_Lib_add1_closure' in:
./Lib.o
Lib.o
ld: 3 duplicate symbols for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
`clang' failed in phase `Linker'. (Exit code: 1)
But, when I simply use ghc --make, it works fine
$ ghc --make Main.hs
[1 of 2] Compiling Lib ( Lib.hs, Lib.o )
[2 of 2] Compiling Main ( Main.hs, Main.o )
Linking Main ...
$ ls -1
Lib.hi
Lib.hs
Lib.o
Main
Main.hi
Main.hs
Main.o
Can anyone explain why ghc --make works while simply ghc does not?
BTW, my ghc's version is
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.10.5
From the GHC docs:
--make
In this mode, GHC will build a multi-module Haskell program automatically, figuring out dependencies for itself. If you have a
straightforward Haskell program, this is likely to be much easier, and
faster, than using make. [..]
This mode is the default if there are any Haskell source files mentioned on the command line, and in this case the --make option can
be omitted.
Hence your line
ghc -o main Main.hs Lib.o
actually means
ghc -o main --make Main.hs Lib.o
which will compile and link Main.hs and all its dependencies (including Lib.o), adding another Lib.o during linking. This will link Lib.o twice, triggering the linker error reported by the OP.
I guess this was changed in GHC after Real World Haskell was written.
I am trying to compile a haskell package without using cabal
Given a correct .conf file, this seems to work
cd src; ghc --make -dynamic -shared -fPIC -package-name adventlib System/IO/Advent.hs System/IO/Test.hs -osuf dyn_o -hisuf dyn_hi -o libHSadventlib-ghc8.6.5.so
cd src; ghc -c --make -package-name adventlib System/IO/Advent.hs System/IO/Test.hs
ar cqs src/libHSadventlib.a src/System/IO/*.o
ghc --make src/MainTest.hs
ghc --make -dynamic src/MainTest.hs -o src/MainTest_dyn
The last two lines test that I can compile an executable binary and link the library both statically and dynamically.
Reading the docs it seems that it should be possible to use -dynamic-too to combine the first two lines in a single ghc run. However, I haven't managed to make that work.
The next line produces the static and dynamic object files, but doesn't create the so file:
cd src; ghc -c --make -dynamic-too -fPIC -package-name adventlib System/IO/Advent.hs System/IO/Test.hs
I can link the so file afterwards with ghc, but then I need to add all the package dependencies manually, missing much of the benefit of using --make
If I remove the -c flag, to make ghc run the link stage like this
cd src; ghc --make -shared -dynamic-too -fPIC -package-name adventlib System/IO/Advent.hs System/IO/Test.hs -o libHSadventlib.a -dyno libHSadventlib-ghc8.6.5.so
Then it seems to fail linking the static library (I guess it is trying to link it as dynamic but using static objects):
cd src; ghc --make -shared -dynamic-too -fPIC -package-name adventlib System/IO/Advent.hs System/IO/Test.hs -o libHSadventlib.a -dyno libHSadventlib-ghc8.6.5.so
[1 of 3] Compiling System.IO.Advent ( System/IO/Advent.hs, System/IO/Advent.o )
[2 of 3] Compiling System.IO.TestInternal ( System/IO/TestInternal.hs, System/IO/TestInternal.o )
[3 of 3] Compiling System.IO.Test ( System/IO/Test.hs, System/IO/Test.o )
Linking libHSadventlib.a ...
/nix/store/0hr45a0pzlh51hhcgynmfjpzff9d3ddv-binutils-2.31.1/bin/ld: /nix/store/gdpi6mrz1wcgmvpnfm9i9la9lpsb8lag-unliftio-0.2.12/lib/ghc-8.6.5/x86_64-linux-ghc-8.6.5/unliftio-0.2.12-Au2Yw1nUjiS94bY0JG3imp/libHSunliftio-0.2.12-Au2Yw1nUjiS94bY0JG3imp.a(Environment.o): relocation R_X86_64_32S against undefined symbol `stg_ap_p_info' can not be used when making a shared object; recompile with -fPIC
/nix/store/0hr45a0pzlh51hhcgynmfjpzff9d3ddv-binutils-2.31.1/bin/ld: /nix/store/7dx9j6hiscwr1a2nq9bjj91p33s9nqgg-unliftio-core-0.1.2.0/lib/ghc-8.6.5/x86_64-linux-ghc-8.6.5/unliftio-core-0.1.2.0-DmlZdkLzX278vkyONsp8WQ/libHSunliftio-core-0.1.2.0-DmlZdkLzX278vkyONsp8WQ.a(Unlift.o): relocation R_X86_64_32S against `.text.unliftiozmcorezm0zi1zi2zi0zmDmlZZdkLzzX278vkyONsp8WQ_ControlziMonadziIOziUnlift_zdp1MonadUnliftIO_info' can not be used when making a shared object; recompile with -fPIC
... etc ...
Am I missing something or doesn't dynamic-too work to create shared libraries?
I have the full working experiment here , for reference.
I am trying out c2hs, and wanted to compile a small example of a shared library with Cabal to get started.
I have the following relevant section of the cabal file test.cabal:
executable libtest.so
hs-source-dirs: src
main-is: Dummy.hs
other-extensions: ForeignFunctionInterface
build-depends: base
default-language: Haskell2010
ghc-options: -no-hs-main -threaded
build-tools: c2hs
Then the source. src/Dummy.hs:
import Test
main :: IO ()
main = return
In the file src/Test.chs
{-# LANGUAGE ForeignFunctionInterface #-}
import Foreign
import Foreign.C
module Android where
And then when I try to compile (cabal configure && cabal build -v) I get the following error message:
Component build order: executable 'libtest.so'
creating dist/build
creating dist/build/autogen
Building test-0.1.0.0...
Preprocessing executable 'libtest.so' for test-0.1.0.0...
Building executable libtest.so...
creating dist/build/libtest.so
creating dist/build/libtest.so/libtest.so-tmp
/opt/ghc/bin/ghc --make -no-link -fbuilding-cabal-package -O -j8 -static
-outputdir dist/build/libtest.so/libtest.so-tmp -odir dist/build
/libtest.so/libtest.so-tmp -hidir dist/build/libtest.so/libtest.so-tmp-stubdir
dist/build/libtest.so/libtest.so-tmp -i -idist/build/libtest.so/libtest.so-tmp
-isrc -idist/build/autogen -Idist/build/autogen
-Idist/build/libtest.so/libtest.so-tmp
-optP-include -optPdist/build/autogen/cabal_macros.h -hide-all-packages
-package-db dist/package.conf.inplace -package-id
base-4.7.0.1-1a55ebc8256b39ccbff004d48b3eb834 -XHaskell2010
src/Dummy.hs -no-hs-main -threaded
src/Dummy.hs:1:8:
Could not find module ‘Test’
Use -v to see a list of the files searched for.
Please, can you tell me what the cause of the error is? What am I missing?
You need to add Test to the other-modules field.
What I want is: cabal to build my modules; make to build this one script.
The script links to Objective-C (see https://github.com/mchakravarty/language-c-inline/tree/master/tests/objc/marshal-array). when I build the script, it fails on the import:
$ make
Main.hs:1:1:
Bad interface file: dist/build/Commands/OSX/Events.hi
Something is amiss; requested module main:Commands.OSX.Events differs from name found in the interface file commands-0.0.0:Commands.OSX.Events
here are some file contents:
$ cat Makefile
PACKAGES = -package template-haskell -package language-c-quote -package language-c-inline -package commands
FRAMEWORKS = -framework Carbon -framework Cocoa -framework Foundation
LDFLAGS = $(PACKAGES) $(FRAMEWORKS)
Main: Main.o
cabal exec -- ghc -o Main Main.o $(LDFLAGS)
Main.o:
cabal build
cabal exec -- ghc -c Main.hs -idist/build/ -v
...
$ cat commands.cabal
exposed-modules: Commands.OSX.Events
hs-source-dirs: sources
...
$ ghc --show-iface dist/build/Commands/OSX/Events.hi
interface commands-0.0.0:Commands.OSX.Events 7083
...
$ cat sources/Commands/OSX/Events.hs
module Commands.OSX.Events where
...
$ cat Main.hs
import Commands.OSX.Events
...
the cabal build is successful, and executable compiles and runs successfully, if I just put everything in the same directory, and ignore cabal.
can I tell GHC that some module is part of some package?
can I make a cabal executable, with these external dependencies?
any other solutions?
explicitly naming the modules package worked:
ghc -package-name commands-0.0.0
http://www.haskell.org/ghc/docs/7.2.1/html/users_guide/packages.html
I've created a Haskell package that makes FFI calls to functions defined in CUDA code. I'd like to compile .cu file to an object (.o) file during package build and force linker to link it in.
So far, I tried to use a technique found this question. I've customized buildHook to:
run nvcc
run default buildHook
create ar library file with nvcc compiled code.
Setup.hs is available here.
This solution has a major disadvantage in restricting this package to static linking. Although cabal produces a shared library, it won't work because it has no way of resolving symbols located in the object file.
Is there a simpler way to link custom code during building?
I do a similar thing. I have a Haskell file which calls CUDA code.
Here's how I compile CUDA libraries and link with Haskell:
$(NVCC) -c -E $(NVCC_OPTS) -o build/file.i file.cu
$(NVCC) -c $(NVCC_OPTS) -o build/file.o file.cu
I then link everything into a C++ Shared Library called LibSO with Haskell options
$(CXX) -shared -Wl,-rpath=\$$$$ORIGIN $(CXX_LINK_LIBS) $(PACKAGE_RPATH) -Lbuild -rdynamic -L/usr/local/lib/ghc-7.6.3 -lHSrts-ghc7.6.3 -o build/LibSO.so build/file.o
where
CXX_LINK_LIBS = -Lbuild -lcudart -lcuda -lpthread -lcupti -lcurand -lnvidia-ml
NVCC_OPTS = --compiler-options -fPIC -maxrregcount=0 --machine 64 --DCUDA
I then take my Haskell files and compile them into o and hi files. (I compile twice because of TemplateHaskell)
ghc -v0 -Wall -rtsopts -threaded -stubdir build -ibuild/ -no-hs-main -o build/iop.o -ohi build/iop.hi -c haskell/iop.lhs
ghc -v0 -Wall -rtsopts -threaded -stubdir build -ibuild/ -no-hs-main -fPIC -dynamic -osuf dyn_o -hisuf dyn_hi -o build/iop.dyn_o -ohi build/iop.dyn_hi -c haskell/iop.lhs
So now we have haskell dynamic objects and a C++ shared library.
In the end, I link a main haskell file with everything:
ghc -optl "-Wl,-rpath=\$$ORIGIN" $(CXX_LINK_LIBS) -Lbuild -rtsopts -threaded -lstdc++ -lLibSO -o build/Main build/iop.dyn_o
Does this sort of help?