I'm having trouble building my Haskell library with GHC 7.8.2 and Cabal 1.20.0.2 on OSX 10.9.3 with both -staticlib and -threaded enabled.
The library I'm building exports several functions using FFI to be called from ObjectiveC in an Xcode project. This works fine with just -staticlib enabled, but now I realize I need to call into my Haskell library from multiple OS-threads simultaneously. But when I add -threaded to ghc-options I get an error when linking:
error: libtool: can't locate file for: -lpthread
error: libtool: file: -lpthread is not an object file (not allowed in a library)
Complete ouput:
$ cabal build
Resolving dependencies...
Configuring dpsync-0.1.0.0...
Building dpsync-0.1.0.0...
Preprocessing library dpsync-0.1.0.0...
[ 1 of 11] Compiling Link ( src/Link.hs, dist/build/Link.o )
...
[11 of 11] Compiling HsCocoa ( src/HsCocoa.hs, dist/build/HsCocoa.o )
Linking liba.a ...
error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: can't locate file for: -lpthread
error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: file: -lpthread is not an object file (not allowed in a library)
The linker command that fails looks like this (... replaces a bunch of -l and -L options):
libtool -static -o liba.a dist/build/HsCocoa.o ... -lCffi -lpthread
Does anyone know what could be wrong?
Entire project on GitHub
Edit:
After discussing this on Haskell Cafe it was suggested that this could be a bug in GHC. I created a ticket here: https://ghc.haskell.org/trac/ghc/ticket/9189
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 would like to start developing for web using yesod framework.
But I can not install yesod.
I'm following the steps suggested:
stack new my-project yesod-sqlite
cd my-project
stack install yesod-bin --install-ghc
But the "stack install yesod-bin --install-ghc" command gives me the following output:
clock-0.7.2: configure
clock-0.7.2: build
basement-0.0.4: configure
file-embed-0.0.10.1: download
hourglass-0.2.10: download
basement-0.0.4: build
file-embed-0.0.10.1: configure
file-embed-0.0.10.1: build
hourglass-0.2.10: configure
hourglass-0.2.10: build
file-embed-0.0.10.1: copy/register
hourglass-0.2.10: copy/register
Progress: 4/93
-- While building custom Setup.hs for package basement-0.0.4 using:
/home/mbaroni/.stack/setup-exe-cache/x86_64-linux-tinfo6-nopie/Cabal-simple_mPHDZzAJ_2.0.1.0_ghc-8.2.2 --builddir=.stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-2.0.1.0 build --ghc-options " -ddump-hi -ddump-to-file -fdiagnostics-color=always"
Process exited with code: ExitFailure 1
Logs have been written to: /home/mbaroni/Computacao/prog/yesod-project/.stack-work/logs/basement-0.0.4.log
Configuring basement-0.0.4...
Preprocessing library for basement-0.0.4..
/usr/bin/ld.gold: error: .stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-2.0.1.0/build/Basement/Terminal/Size_hsc_make.o: requires dynamic R_X86_64_32 reloc which may overflow at runtime; recompile with -fPIC
/usr/bin/ld.gold: error: .stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-2.0.1.0/build/Basement/Terminal/Size_hsc_utils.o: requires dynamic R_X86_64_PC32 reloc against 'vprintf' which may overflow at runtime; recompile with -fPIC
collect2: error: ld returned 1 exit status
linking .stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-2.0.1.0/build/Basement/Terminal/Size_hsc_make.o failed (exit code 1)
command was: /usr/bin/gcc .stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-2.0.1.0/build/Basement/Terminal/Size_hsc_make.o .stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-2.0.1.0/build/Basement/Terminal/Size_hsc_utils.o -o .stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-2.0.1.0/build/Basement/Terminal/Size_hsc_make -fuse-ld=gold -fno-PIE -fno-stack-protector -fuse-ld=gold -L/home/mbaroni/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.2.2/lib/ghc-8.2.2/base-4.10.1.0 -Wl,-R,/home/mbaroni/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.2.2/lib/ghc-8.2.2/base-4.10.1.0 -L/home/mbaroni/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.2.2/lib/ghc-8.2.2/integer-gmp-1.0.1.0 -Wl,-R,/home/mbaroni/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.2.2/lib/ghc-8.2.2/integer-gmp-1.0.1.0 -lgmp -L/home/mbaroni/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.2.2/lib/ghc-8.2.2/ghc-prim-0.5.1.1 -Wl,-R,/home/mbaroni/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.2.2/lib/ghc-8.2.2/ghc-prim-0.5.1.1 -L/home/mbaroni/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.2.2/lib/ghc-8.2.2/rts -Wl,-R,/home/mbaroni/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.2.2/lib/ghc-8.2.2/rts -lm -lrt -ldl -lpthread
Any idea about what could be the cause of the problem would be greatly appreciated.
My environment:
stack --version
Version 1.6.1, Git revision f25811329bbc40b0c21053a8160c56f923e1201b (5435 commits) x86_64 hpack-0.20.0
ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.2.2
uname -a
Linux mbaroni 4.12.13-1-ARCH #1 SMP PREEMPT Fri Sep 15 06:36:43 UTC 2017 x86_64 GNU/Linux
Thanks for helping!
I finally figured out what was the problem and I was able to solve it in my environment.
Reason
It seems that GCC enabled PIE (Position Independent Executable) by default and stack (which uses GCC in the back) does not expect this, causing the reported problem at linking stage (source).
Solution
As suggested here the solution was to configure stack to pass gcc the right flags to correct this.
This is done editing the file "~/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.0.1/lib/ghc-8.0.1/settings" in my case.
I had to modify the configuration of 3 lines as follows:
...
("C compiler flags", "-fno-PIE -fno-stack-protector -fPIC"),
("C compiler link flags", "-no-pie -fuse-ld=gold"),
("C compiler supports -no-pie", "YES"),
...
Best.
I'm trying to use the req package (http://hackage.haskell.org/package/req) in a Haskell project, with stack.
So far, I've done stack new my-project, stack setup, stack build and stack exec my-project-exe all fine.
Have added req to the cabal file like so:
name: my-project
version: 0.1.0.0
synopsis: Short description of your package
homepage: https://github.com/githubuser/#readme
license: BSD3
license-file: LICENSE
author: Author name here
maintainer: example#example.com
copyright: 2017 Author name here
category: Web
build-type: Simple
extra-source-files: README.md
cabal-version: >=1.10
library
hs-source-dirs: src
exposed-modules: Lib
build-depends: base >= 4.7 && < 5
, req -- THIS IS THE LINE IVE ADDED
default-language: Haskell2010
executable my-project-exe
hs-source-dirs: app
main-is: Main.hs
ghc-options: -threaded -rtsopts -with-rtsopts=-N
build-depends: base
, my-project
default-language: Haskell2010
test-suite my-project-test
type: exitcode-stdio-1.0
hs-source-dirs: test
main-is: Spec.hs
build-depends: base
, my-project
ghc-options: -threaded -rtsopts -with-rtsopts=-N
default-language: Haskell2010
source-repository head
type: git
location: https://github.com/githubuser/my-project
And finally, cut and paste the example from the req readme into src/Lib.hs, changing the function name like so:
{-# LANGUAGE OverloadedStrings #-}
{-# OPTIONS_GHC -fno-warn-orphans #-}
module Lib
( someFunc
) where
import Control.Exception (throwIO)
import Network.HTTP.Req
import Data.Aeson
-- Just make your monad stack an instance of MonadHttp in your application
-- and start making requests, enjoy automatic connection sharing.
instance MonadHttp IO where
handleHttpException = throwIO
someFunc :: IO ()
someFunc = do
let payload = object
[ "foo" .= (10 :: Int)
, "bar" .= (20 :: Int) ]
-- One function, full power and flexibility.
r <- req POST -- method
(https "httpbin.org" /: "post") -- safe by construction URL
(ReqBodyJson payload) -- use built-in options or add your own
jsonResponse -- specify how to interpret response
mempty -- query params, headers, explicit port number, etc.
print (responseBody r :: Value)
And now stack build is erroring:
%> stack build
basement-0.0.4: configure
basement-0.0.4: build
zlib-0.6.1.2: configure
aeson-1.1.2.0: download
zlib-0.6.1.2: build
network-2.6.3.2: configure
th-lift-instances-0.1.11: download
aeson-1.1.2.0: configure
aeson-1.1.2.0: build
th-lift-instances-0.1.11: configure
th-lift-instances-0.1.11: build
th-lift-instances-0.1.11: copy/register
aeson-1.1.2.0: copy/register
Progress: 5/28
-- While building package network-2.6.3.2 using:
/tmp/stack7830/network-2.6.3.2/.stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-1.24.2.0/setup/setup --builddir=.stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-1.24.2.0 configure --with-ghc=/home/liam/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.0.2/bin/ghc --with-ghc-pkg=/home/liam/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.0.2/bin/ghc-pkg --user --package-db=clear --package-db=global --package-db=/home/liam/.stack/snapshots/x86_64-linux-tinfo6-nopie/lts-9.14/8.0.2/pkgdb --libdir=/home/liam/.stack/snapshots/x86_64-linux-tinfo6-nopie/lts-9.14/8.0.2/lib --bindir=/home/liam/.stack/snapshots/x86_64-linux-tinfo6-nopie/lts-9.14/8.0.2/bin --datadir=/home/liam/.stack/snapshots/x86_64-linux-tinfo6-nopie/lts-9.14/8.0.2/share --libexecdir=/home/liam/.stack/snapshots/x86_64-linux-tinfo6-nopie/lts-9.14/8.0.2/libexec --sysconfdir=/home/liam/.stack/snapshots/x86_64-linux-tinfo6-nopie/lts-9.14/8.0.2/etc --docdir=/home/liam/.stack/snapshots/x86_64-linux-tinfo6-nopie/lts-9.14/8.0.2/doc/network-2.6.3.2 --htmldir=/home/liam/.stack/snapshots/x86_64-linux-tinfo6-nopie/lts-9.14/8.0.2/doc/network-2.6.3.2 --haddockdir=/home/liam/.stack/snapshots/x86_64-linux-tinfo6-nopie/lts-9.14/8.0.2/doc/network-2.6.3.2 --dependency=base=base-4.9.1.0 --dependency=bytestring=bytestring-0.10.8.1 --dependency=unix=unix-2.7.2.1
Process exited with code: ExitFailure 1
Logs have been written to: /home/liam/code/forecast-compare/.stack-work/logs/network-2.6.3.2.log
[1 of 2] Compiling Main ( /tmp/stack7830/network-2.6.3.2/Setup.hs, /tmp/stack7830/network-2.6.3.2/.stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-1.24.2.0/setup/Main.o )
[2 of 2] Compiling StackSetupShim ( /home/liam/.stack/setup-exe-src/setup-shim-mPHDZzAJ.hs, /tmp/stack7830/network-2.6.3.2/.stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-1.24.2.0/setup/StackSetupShim.o )
Linking /tmp/stack7830/network-2.6.3.2/.stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-1.24.2.0/setup/setup ...
Configuring network-2.6.3.2...
configure: WARNING: unrecognized options: --with-compiler
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking for gcc... /usr/bin/gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... configure: error: in `/tmp/stack7830/network-2.6.3.2':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details
-- While building package zlib-0.6.1.2 using:
/home/liam/.stack/setup-exe-cache/x86_64-linux-tinfo6-nopie/Cabal-simple_mPHDZzAJ_1.24.2.0_ghc-8.0.2 --builddir=.stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-1.24.2.0 build --ghc-options " -ddump-hi -ddump-to-file"
Process exited with code: ExitFailure 1
Logs have been written to: /home/liam/code/forecast-compare/.stack-work/logs/zlib-0.6.1.2.log
Configuring zlib-0.6.1.2...
Building zlib-0.6.1.2...
Preprocessing library zlib-0.6.1.2...
/usr/bin/ld: .stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-1.24.2.0/build/Codec/Compression/Zlib/Stream_hsc_make.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
linking .stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-1.24.2.0/build/Codec/Compression/Zlib/Stream_hsc_make.o failed (exit code 1)
command was: /usr/bin/gcc .stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-1.24.2.0/build/Codec/Compression/Zlib/Stream_hsc_make.o .stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-1.24.2.0/build/Codec/Compression/Zlib/Stream_hsc_utils.o -o .stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-1.24.2.0/build/Codec/Compression/Zlib/Stream_hsc_make -fno-PIE -fno-stack-protector -lz -L/home/liam/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.0.2/lib/ghc-8.0.2/bytestring-0.10.8.1 -Wl,-R,/home/liam/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.0.2/lib/ghc-8.0.2/bytestring-0.10.8.1 -L/home/liam/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.0.2/lib/ghc-8.0.2/deepseq-1.4.2.0 -Wl,-R,/home/liam/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.0.2/lib/ghc-8.0.2/deepseq-1.4.2.0 -L/home/liam/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.0.2/lib/ghc-8.0.2/array-0.5.1.1 -Wl,-R,/home/liam/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.0.2/lib/ghc-8.0.2/array-0.5.1.1 -L/home/liam/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.0.2/lib/ghc-8.0.2/base-4.9.1.0 -Wl,-R,/home/liam/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.0.2/lib/ghc-8.0.2/base-4.9.1.0 -L/home/liam/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.0.2/lib/ghc-8.0.2/integer-gmp-1.0.0.1 -Wl,-R,/home/liam/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.0.2/lib/ghc-8.0.2/integer-gmp-1.0.0.1 -lgmp -L/home/liam/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.0.2/lib/ghc-8.0.2/ghc-prim-0.5.0.0 -Wl,-R,/home/liam/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.0.2/lib/ghc-8.0.2/ghc-prim-0.5.0.0 -L/home/liam/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.0.2/lib/ghc-8.0.2/rts -Wl,-R,/home/liam/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.0.2/lib/ghc-8.0.2/rts -lm -lrt -ldl -lpthread
-- While building package basement-0.0.4 using:
/home/liam/.stack/setup-exe-cache/x86_64-linux-tinfo6-nopie/Cabal-simple_mPHDZzAJ_1.24.2.0_ghc-8.0.2 --builddir=.stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-1.24.2.0 build --ghc-options " -ddump-hi -ddump-to-file"
Process exited with code: ExitFailure 1
Logs have been written to: /home/liam/code/forecast-compare/.stack-work/logs/basement-0.0.4.log
Configuring basement-0.0.4...
Building basement-0.0.4...
Preprocessing library basement-0.0.4...
/usr/bin/ld: .stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-1.24.2.0/build/Basement/Terminal/Size_hsc_make.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
linking .stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-1.24.2.0/build/Basement/Terminal/Size_hsc_make.o failed (exit code 1)
command was: /usr/bin/gcc .stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-1.24.2.0/build/Basement/Terminal/Size_hsc_make.o .stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-1.24.2.0/build/Basement/Terminal/Size_hsc_utils.o -o .stack-work/dist/x86_64-linux-tinfo6-nopie/Cabal-1.24.2.0/build/Basement/Terminal/Size_hsc_make -fno-PIE -fno-stack-protector -L/home/liam/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.0.2/lib/ghc-8.0.2/base-4.9.1.0 -Wl,-R,/home/liam/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.0.2/lib/ghc-8.0.2/base-4.9.1.0 -L/home/liam/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.0.2/lib/ghc-8.0.2/integer-gmp-1.0.0.1 -Wl,-R,/home/liam/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.0.2/lib/ghc-8.0.2/integer-gmp-1.0.0.1 -lgmp -L/home/liam/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.0.2/lib/ghc-8.0.2/ghc-prim-0.5.0.0 -Wl,-R,/home/liam/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.0.2/lib/ghc-8.0.2/ghc-prim-0.5.0.0 -L/home/liam/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.0.2/lib/ghc-8.0.2/rts -Wl,-R,/home/liam/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.0.2/lib/ghc-8.0.2/rts -lm -lrt -ldl -lpthread
Any help much appreciated!
This issue has been plaguing users of Arch Linux for a few months. It appears to be related to the ncurses library, and possibly due to Arch Linux dynamically linking Haskell packages, whilst most (all?) other distros use static linking.
The current work around involves using the ghc-build: nopie option for the stack ghc version, and installing ncurses5-compat-libs from the AUR.
If you wish to set this globally, you can set it in your ~/.stack/config.yaml, so it applies to all projects you build with stack.
A bug report is currently open here, and some related discussion can be found on the arch forums or the stack github.
For me deleting ~/.stack and using
stack setup --ghc-build=ncurses6
and adding
ghc-build: ncurses6
to
~/.stack/config.yaml
resolved this.
Addendum:
ghc-build: tinfo6
and
stack setup --ghc-build=tinfo6
worked even better for me.
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?
have a bug with libClang, then i install it with cabal at the end i get:
[13 of 13] Compiling Clang ( src/Clang.hs, dist/build/Clang.o )
In file included from ./src/Clang/FFI_stub_ffi.h:6,
from src/Clang/FFI_stub_ffi.c:4:0:
/usr/local/lib/ghc-7.0.3/include/HsFFI.h:29:0:
warning: "__STDC_LIMIT_MACROS" redefined
<command-line>:0:0:
note: this is the location of the previous definition
src/Clang/FFI_stub_ffi.c: In function ‘prim_getCString’:
src/Clang/FFI_stub_ffi.c:33:0:
warning: assignment discards qualifiers from pointer target type
src/Clang/FFI_stub_ffi.c: In function ‘prim_toggleCrashRecovery’:
src/Clang/FFI_stub_ffi.c:2181:0:
warning: implicit declaration of function ‘clang_toggleCrashRecovery’
Registering LibClang-0.0.9...
when i now want to compile a script with ghc that uses Clang i get:
ghc --make test.hs -L.
[1 of 1] Compiling Main ( test.hs, test.o )
Linking test ...
/home/foo/.cabal/lib/LibClang-0.0.9/ghc-7.0.3/libHSLibClang-0.0.9.a(FFI_stub_ffi.o): In function `prim_toggleCrashRecovery':
FFI_stub_ffi.c:(.text+0x1577): undefined reference to `clang_toggleCrashRecovery'
collect2: ld returned 1 exit status
someone a idea what to do?
I can reproduce this on Arch Linux / x86_64: my libclang build emits a warning about the missing symbol,
src/Clang/FFI_stub_ffi.c:2181:1:
warning: implicit declaration of function ‘clang_toggleCrashRecovery’
[-Wimplicit-function-declaration]
Registering LibClang-0.0.9...
Installing library in /home/dons/.cabal/lib/LibClang-0.0.9/ghc-7.0.3
Registering LibClang-0.0.9...
and linking a test program:
import Clang
main = print "yes"
fails with:
$ ghc --make A.hs
Linking A ...
/home/dons/.cabal/lib/LibClang-0.0.9/ghc-7.0.3/libHSLibClang-0.0.9.a(FFI_stub_ffi.o):
In function `prim_toggleCrashRecovery':
FFI_stub_ffi.c:(.text+0x3513): undefined reference to `clang_toggleCrashRecovery'
collect2: ld returned 1 exit status
The process of solving these kind of linker errors is to identify which C library archive that symbol lives in. Searching in my libclang install, I can't find this symbol:
$ find . -type f -exec grep toggleCrashRecovery {} \;
$ grep toggleCrashRecovery /usr/lib/llvm/*
$ grep toggleCrashRecovery /usr/lib/llvm/*/*
zsh: no matches found: /usr/lib/llvm/*/*
which is a clue that it might be something only available in a different version of libclang. I'm using clang/llvm 2.9, which does not have this symbol, while google does turn up some older headers that do include it. So my best guess is that this symbol is no longer available in LLVM, and thus the current haskell/libclang package depends on LLVM/Clang 2.8.
Solution:
Download the libclang source,
$ cabal unpack libclang
and patch it to remove references to the toggle* functions.
$ ghc --make A.hs
[1 of 1] Compiling Main ( A.hs, A.o )
Linking A ...
A patched version is here: http://www.galois.com/~dons/tmp/LibClang-0.0.10.tar.gz
I've also forwarded this info to the author.
Thanks Don for the quick fix.
This issue is fixed with the latest version on Hackage:
http://hackage.haskell.org/package/LibClang-0.1.0
Please "cabal update" and you should be good to go.
Alternatively, you could get the source from https://github.com/chetant/LibClang