default to shared-llvm for ghc 7.8 (so that by default ghci works)

[cartazio]

ghci in 7.8 supports llvm-general, but only if linked against shared-llvm

i'll test if static lnking works for compiled code, but having ghci interaction work by default would be a huge win!

[cartazio]

i'll test more this evening

[bscarlet]

What goes wrong with --enable-shared but not -fshared-llvm?

[cartazio]

this (note in GHCI in 7.8 RC, which means its using a dylib / dynlinking for ghci)

Prelude> import LLVM.General as LG
Prelude LG> LG.
LG.Module                LG.moduleObject          LG.writeAssemblyToFile
LG.linkModules           LG.moduleString          LG.writeBitcodeToFile
LG.moduleAST             LG.withModuleFromAST     LG.writeObjectToFile
LG.moduleAssembly        LG.withModuleFromString
Prelude LG> let f x = LG.linkModules  x
Loading package transformers-0.3.0.0 ... linking ... done.
Loading package pretty-1.1.1.1 ... linking ... done.
Loading package array-0.5.0.0 ... linking ... done.
Loading package deepseq-1.3.0.2 ... linking ... done.
Loading package containers-0.5.4.0 ... linking ... done.
Loading package bytestring-0.10.4.0 ... linking ... done.
Loading package mtl-2.1.2 ... linking ... done.
Loading package text-1.1.0.0 ... linking ... done.
Loading package parsec-3.1.5 ... linking ... done.
Loading package old-locale-1.0.0.6 ... linking ... done.
Loading package time-1.4.1 ... linking ... done.
Loading package unix-2.7.0.0 ... linking ... done.
Loading package setenv-0.1.1 ... linking ... done.
Loading package template-haskell ... linking ... done.
Loading package llvm-general-pure-3.3.8.2 ... linking ... done.
Loading package utf8-string-0.3.7 ... linking ... done.
Loading package llvm-general-3.3.8.2 ... linking ... <interactive>: 
lookupSymbol failed in relocateSection (RELOC_GOT)
/usr/local/Cellar/llvm33/3.3/lib/llvm-3.3/lib/libLLVMSupport.a: unknown symbol `___dso_handle'
ghc: unable to load package `llvm-general-3.3.8.2'

[bscarlet]

Is this a GHCi thing or a general problem with having a shared llvm-general itself built with static llvm libraries?

[cartazio]

I think its a general thing for shared libs. if i do a rebuild sans -fshared-llvm i get

[58 of 83] Compiling LLVM.General.Internal.Global ( src/LLVM/General/Internal/Global.hs, dist/build/LLVM/General/Internal/Global.o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package array-0.5.0.0 ... linking ... done.
Loading package deepseq-1.3.0.2 ... linking ... done.
Loading package bytestring-0.10.4.0 ... linking ... done.
Loading package utf8-string-0.3.7 ... linking ... done.
Loading package containers-0.5.4.0 ... linking ... done.
Loading package transformers-0.3.0.0 ... linking ... done.
Loading package mtl-2.1.2 ... linking ... done.
Loading package text-1.1.0.0 ... linking ... done.
Loading package parsec-3.1.5 ... linking ... done.
Loading package old-locale-1.0.0.6 ... linking ... done.
Loading package time-1.4.1 ... linking ... done.
Loading package unix-2.7.0.0 ... linking ... done.
Loading package setenv-0.1.1 ... linking ... done.
Loading package pretty-1.1.1.1 ... linking ... done.
Loading package template-haskell ... linking ... done.
Loading package llvm-general-pure-3.4.0.0 ... linking ... done.
[59 of 83] Compiling LLVM.General.Internal.Type ( src/LLVM/General/Internal/Type.hs, dist/build/LLVM/General/Internal/Type.o )
[60 of 83] Compiling LLVM.General.Internal.Constant ( src/LLVM/General/Internal/Constant.hs, dist/build/LLVM/General/Internal/Constant.o )
ld: illegal text reloc in '_llvmzmgeneralzm3zi4zi0zi0_LLVMziGeneralziInternalziInstructionDefs_instrP1_info' to '_llvmzmgeneralzm3zi4zi0zi0_LLVMziGeneralziInternalziFFIziLLVMCTypes_zdfDataCPPOpcode_closure' for architecture x86_64
collect2: error: ld returned 1 exit status

this is because on x86 / arm, GHCI now uses dylinking rather than static linking, and TH uses GHCI. And LLVM-General uses TH and hence GHCI to build itself. (and some of the modules with TH depend on other modules which link into LLVM)

If it weren't for the TH usage, i'd suspect that (at least in compiled code outside of ghci) the static linking would be fine... but ghci and thence TH need dylinking for 7.8 on platforms when applicable (and its kinda awesome being able to use llvm-general in ghci! )

[bscarlet]

Now I'm more confused. I thought that GHCi and hence TH didn't work with llvm-general prior to the new 7.8 stuff at all; so I'd been (hastily, apparently) assuming that the TH usage within llvm-general avoided needing to link against llvm.

Did llvm-general + ghci work in any combination prior to 7.8? If so, how did the TH in llvm-general work?

[cartazio]

Hrmmm. Honestly, the answer in my prior remark is largely conjecture, and I find linkers confusing :)

It especially doesn't help that the ghci static linker is a unique artifact to ghc, and isn't the standard system static / dynamic linkers. Though you can read the source to see a bit of this https://github.com/ghc/ghc/blob/master/rts/Linker.c#L248-L272 (that seems to touch on part of the issue)

and yes, llvm-general + ghci prior to 7.8 didn't work, though i'm happy to do a sandboxed setup sometime tomorrow to double check that if you like

[cartazio]

I asked Austin (thoughtpolice) on IRC and he's got a pretty good explanation (or at least the start of one )

does "unknown symbol `___dso_handle'" mean anything?
[14:02:03-13:30:13] i'd have to look more closely later, but this doesn't really surprise me, i think - ghci is using the system linker, which has no clue how to dynamically load/relocate a static archive (the code isn't position independent.)

[cartazio]

looks like this may be a manifestation of https://ghc.haskell.org/trac/ghc/ticket/8696#comment:9

[cartazio]

I got things building with static linked llvm, BUT then it fails in ghci

*Main> let f x  = parseStringLLVM  x
Loading package array-0.5.0.0 ... linking ... done.
Loading package deepseq-1.3.0.2 ... linking ... done.
Loading package bytestring-0.10.4.0 ... linking ... done.
Loading package containers-0.5.4.0 ... linking ... done.
Loading package pretty-1.1.1.1 ... linking ... done.
Loading package transformers-0.3.0.0 ... linking ... done.
Loading package mtl-2.1.2 ... linking ... done.
Loading package text-1.1.0.0 ... linking ... done.
Loading package parsec-3.1.5 ... linking ... done.
Loading package old-locale-1.0.0.6 ... linking ... done.
Loading package time-1.4.1 ... linking ... done.
Loading package unix-2.7.0.0 ... linking ... done.
Loading package setenv-0.1.1 ... linking ... done.
Loading package template-haskell ... linking ... done.
Loading package llvm-general-pure-3.4.0.0 ... linking ... done.
Loading package utf8-string-0.3.7 ... linking ... done.
Loading package llvm-general-3.4.0.0 ... can't load .so/.DLL for: /Users/carter/.cabal/lib/x86_64-osx-ghc-7.8.20140130/llvm-general-3.4.0.0/libHSllvm-general-3.4.0.0-ghc7.8.20140130.dylib (dlopen(/Users/carter/.cabal/lib/x86_64-osx-ghc-7.8.20140130/llvm-general-3.4.0.0/libHSllvm-general-3.4.0.0-ghc7.8.20140130.dylib, 9): Symbol not found: __ZNSs4_Rep20_S_empty_rep_storageE
  Referenced from: /Users/carter/.cabal/lib/x86_64-osx-ghc-7.8.20140130/llvm-general-3.4.0.0/libHSllvm-general-3.4.0.0-ghc7.8.20140130.dylib
  Expected in: flat namespace
 in /Users/carter/.cabal/lib/x86_64-osx-ghc-7.8.20140130/llvm-general-3.4.0.0/libHSllvm-general-3.4.0.0-ghc7.8.20140130.dylib)

[hberntsen]

With GHC 7.8.2 and then starting ghci via cabal repl I got something like Loading package llvm-general ... linking ... segmenation fault or illegal instruction. I had installed the llvm-general with the --enable-shared flag. Installing llvm-general with both the -fshared-llvm and --enable-shared solved the problem for me. I hope this helps anyone with the same problem.

[rietmann]

I wanted to clarify for anyone having trouble (and confirm @hberntsen's comment). With ghc-7.8.3, llvm-general-3.4.4.0, and llvm 3.4.2.

(Re)Compile llvm with shared libraries

./configure --enable-shared
make
sudo make install
# fix shared library search (possibly unnecessary)
# on ubuntu 12.04
# add "/usr/local/lib/" to /etc/ld.so.conf.d/llvm.conf (on Ubunut at least)
sudo ldconfig

Install llvm-general so that cabal repl works

cabal install llvm-general -fshared-llvm