Runtime link error on Linux

[kierdavis]

I'm having trouble running a program using the llvm-general library. Both this library and my program compile fine, but upon running I get this error:

myprogram.hs: /usr/local/lib/libLLVMSupport.a: unknown symbol `_ZTVN4llvm14error_categoryE'
myprogram.hs: myprogram.hs: unable to load package `llvm-general-3.3.5.0'

I've tried both building LLVM 3.3 from source as well as installing the same version from the system's package manager, with this error consistently produced.

I'm not sure if this is related to llvm-general or a problem with LLVM itself, but I felt it would be best to raise the issue here first.

Thanks in advance.

---

uname -a: Linux renegade 3.9-1-amd64 #1 SMP Debian 3.9.8-1 x86_64 GNU/Linux LLVM version: 3.3 llvm-general version: 3.3.5.0 (from Hackage)

---

Edit: Since mentioning what the program does normally helps in these situations, at the moment it simply constructs an AST from a small input program and pretty-prints it to the console; tools such as the code generator or optimisation passes are not being used yet.

[bscarlet]

Did you build the cabal package with either --enable-shared or -fshared-llvm when you built the cabal package? If not, the default would be to build a statically-linked haskell package, itself statically linked against llvm. In that case I'm somewhat surprised you're getting a link error at runtime - I don't understand the behavior of your toolchain.

Are you able to share the source code of an example that triggers this problem?

Also, are you able to run the test suite in the cabal package?

[kierdavis]

I didn't use any extra flags when building the package - I'll try that tomorrow when I'm back at my computer.

I've also realised now that I've thought through the building process, that I've been using runhaskell to build the program. It's probable that this error was occurring when the final program was being linked, so I'll try compiling with ghc and running seperately and seeing if this holds true.

I'll also post a link to my source code tomorrow, again when I'm back on my computer. On 2 Aug 2013 01:02, "Benjamin S. Scarlet" notifications@github.com wrote:

Did you build the cabal package with either --enable-shared or -fshared-llvm when you built the cabal package? If not, the default would be to build a statically-linked haskell package, itself statically linked against llvm. In that case I'm somewhat surprised you're getting a link error at runtime - I don't understand the behavior of your toolchain.

Are you able to share the source code of an example that triggers this problem?

— Reply to this email directly or view it on GitHubhttps://github.com/bscarlet/llvm-general/issues/63#issuecomment-21978597 .

[bscarlet]

I wouldn't expect the --enable-shared or -fshared-llvm flags to help - I was asking looking for an explanation of when you saw the error, but you've explained that with the note about using runhaskell. Let me know what you find when build with ghc.

Also - does the location of libLLVMSupport.a in that error message look right to you? Is the LLVM you're using installed in /usr/local?

[kierdavis]

Oddly, the program compiles and runs fine when compiled with ghc and run standalone - it seems to just be runhaskell's linking that screws it up.

I'll do a bit of investigating into why it doesn't work with runhaskell, but for now the problem is resolved. Thanks for the help :)

[iainnicol]

Can this be reopened, please? Unfortunately I'm experiencing this exact same obscure issue.

I'm build-depending upon llvm-general in the cabal file. I'm not directly using runhaskell or ghci. However, simply using Template Haskell:

{-# LANGUAGE TemplateHaskell #-}

module Main (main) where

import qualified Control.Lens as L

data Foo = Foo { _bar :: Int }
L.makeLenses ''Foo

main = return ()

triggers the error:

Loading package llvm-general-3.3.8.2 ... linking ... ghc: /usr/lib/llvm-3.3/lib/libLLVMSupport.a: unknown symbol `_ZTVN4llvm14error_categoryE'
ghc: unable to load package `llvm-general-3.3.8.2'

Of note, like Kier, I'm also on x86_64 Linux. GHC v7.6.3. LLVM version number seems unimportant; it happens with both llvm-general v3.3.x and llvm-general v3.4.x.

I found a blog post which led me to a GHC issue. With any luck it's the same issue, and hence is fixed in GHC 7.8.

[bscarlet]

Could you please post the .cabal file you're using?

[iainnicol]

Thanks for reopening.

It's still failing for me with GHC 7.8 HEAD, but I think in a better way. The new error message is

Loading package llvm-general-3.3.8.2 ... linking ... ghc: /usr/lib/llvm-3.3/lib/libLLVMSupport.a: unknown symbol `__dso_handle'
ghc: unable to load package `llvm-general-3.3.8.2'

I think this is a subtle improvement. __dso_handle isn't any old symbol, apparently; it's part of the focus of GHC bug #3333. With any luck the patches on that bug fix this.

I was using the following trivial cabal file with the Main.hs from my previous comment.

name:               llvmth
description:        -
version:            0.1.0
cabal-version:      >=1.18
build-type:         Simple

executable llvmth
  main-is: src/Main.hs
  default-language: Haskell2010
  other-extensions:
    TemplateHaskell
  build-depends:
    base >= 4.6 && < 5,
    lens,
    llvm-general == 3.3.8.2

[bscarlet]

I can reproduce your problem on OS X, but I think your diagnosis is correct - I don't think this is a problem with llvm-general, but rather a problem with GHC which is a problem for llvm-general. As such I'm inclined to close the bug as I don't think there's anything I can do to help.

[iainnicol]

Agreed. Thanks.

[bscarlet]

If the GHC bugs which seem to be related get fixed and this issue persists, we can re-open this issue.