GithubHelp home page GithubHelp logo

bos / llvm Goto Github PK

View Code? Open in Web Editor NEW
103.0 12.0 34.0 1.26 MB

Haskell bindings to the LLVM compiler infrastructure project.

License: Other

Haskell 89.18% C++ 5.59% C 3.75% M4 1.32% Makefile 0.15%

llvm's Introduction

Notice

Please note that this package is deprecated and the Haskell LLVM community has shifted to llvm-hs, which can be found on
Hackage and Github.

if you have any questions you can find many members of the Haskell LLVM community on the #haskell-llvm freenode irc channel.

Haskell LLVM bindings

This package provides Haskell bindings for the popular LLVM compiler infrastructure project.

Compatibility

We try to stay up to date with LLVM releases. The current version of this package is compatible with LLVM 2.9 and 2.8. Please understand that the package may or may not work against older LLVM releases; we don't have the time or resources to test across multiple releases.

Configuration

By default, when you run cabal install, the Haskell bindings will be configured to look for LLVM in /usr/local.

If you have LLVM installed in a different location, e.g. /usr, you can tell the configure script where to find it as follows:

cabal install --configure-option=--with-llvm-prefix=/usr

Package status - what to expect

This package is still under development.

The high level bindings are currently incomplete, so there are some limits on what you can do. Adding new functions is generally easy, though, so don't be afraid to get your hands dirty.

The high level interface is mostly safe, but the type system cannot protect against everything that can go wrong, so take care. And, of course, there's no way to guarantee anything about the generated code.

Staying in touch

There is a low-volume mailing list named [email protected]. If you use the LLVM bindings, you should think about joining.

If you want to contribute patches, please clone a copy of the git repository:

git clone git://github.com/bos/llvm

Patches are best submitted via the github "pull request" interface.

To file a bug or a request for an enhancement, please use the github issue tracker.

llvm's People

Contributors

augustss avatar batterseapower avatar bharath1097 avatar bos avatar cartazio avatar derivingshow avatar directxman12 avatar erikd avatar iainlane avatar iliastsi avatar johnlato avatar mattias-lundell avatar mchakravarty avatar mkmks avatar nathanhowell avatar olajep avatar osa1 avatar ralith avatar scottgw avatar sdiehl avatar thielema avatar wesleywiser avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

llvm's Issues

Build Failure LLVM-TF-3.0.0.1

In Type.hs

There is a typo.

Line 75, FFI.fP128Type should be FFI.fp128Type
-- error is the case of "p"

In LLVM.Core.Instructions

Line 177 has a type error. p :: Int when the function expects a CInt. This is because
FFI.cmpInstGetPredicate
returns an IO Int not IO CInt
Not sure how best to fix this.

Trying to build llvm bindings for legacy code

Hi, as part of a free time project I've tried and failed multiple times to get this project to build. I'm stuck at getting these llvm bindings to build. I gave up trying to get llvm-0.10.0.1 to build (the actual dependency). it seemed just to old.

The last couple of tries I've tried to get llvm-3.2.0.2 to build. At least now I can use Vagrant to get an environment that is more likely to work, Currently "precise32". So I have installed llvm 2.9 and clang 2.9 with apt-get. At least that worked now. But when I try to build llvm-3.2.0.2 llvm-base-3.2.0.2 complains about missing c headers (Core.h, Linker.h). I've managed to hack myself past some such problems but there are always new ones. Seems there is some version discrepancy.

Most preferably I would get llvm-0.10.0.1 to build though.

Does anyone have any pointers for getting at least one of the versions of the llvm bindings to build on an ubuntu machine (precise pangolin or other - I'm using Vagrant so I can easily change)? What version of build tools do I need (g++/gcc)? Any recommendations?

LLVMAddLoopIndexSplitPass link error

Apparently Scalar.hsc still references LLVMAddLoopIndexSplitPass even though it has been removed:

http://www.mail-archive.com/[email protected]/msg10326.html

As a result, I'm getting link errors like this:

"""
$ ghc --make Main.hs
[1 of 1] Compiling Main ( Main.hs, Main.o )
Linking Main ...
Undefined symbols:
"_LLVMAddLoopIndexSplitPass", referenced from:
_smpv_info in libHSllvm-0.9.1.2.a(Scalar.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status
"""

I'm not sure which versions of LLVM are affected. I'm using LLVM HEAD (as of today), so this may be a recent change.

Linking failure when using llvm-base

I'm on Arch Linux using llvm-3.0-1. I did a cabal install of llvm-base-3.0.0.0, and everything went fine.

But when I try to build a program that imports LLVM.FFI.Core, I get

[4 of 4] Compiling Main             ( Main.hs, Main.o )
Linking Main ...
/home/karl/.cabal/lib/llvm-base-3.0.0.0/ghc-7.0.3/libHSllvm-base-3.0.0.0.a(Core.o): In function `s9Pa_info':
(.text+0xa432): undefined reference to `LLVMOpaqueTypeInContext'
/home/karl/.cabal/lib/llvm-base-3.0.0.0/ghc-7.0.3/libHSllvm-base-3.0.0.0.a(Core.o): In function `sbh8_info':
(.text+0xf902): undefined reference to `LLVMResolveTypeHandle'
/home/karl/.cabal/lib/llvm-base-3.0.0.0/ghc-7.0.3/libHSllvm-base-3.0.0.0.a(Core.o): In function `sbhK_info':
(.text+0xf99c): undefined reference to `LLVMRefineType'
/home/karl/.cabal/lib/llvm-base-3.0.0.0/ghc-7.0.3/libHSllvm-base-3.0.0.0.a(Core.o): In function `sblI_info':
(.text+0xfd6d): undefined reference to `LLVMDisposeTypeHandle'
/home/karl/.cabal/lib/llvm-base-3.0.0.0/ghc-7.0.3/libHSllvm-base-3.0.0.0.a(Core.o): In function `sbnj_info':
(.text+0xfee2): undefined reference to `LLVMCreateTypeHandle'
/home/karl/.cabal/lib/llvm-base-3.0.0.0/ghc-7.0.3/libHSllvm-base-3.0.0.0.a(Core.o): In function `scFX_info':
(.text+0x147fa): undefined reference to `LLVMBuildUnwind'
/home/karl/.cabal/lib/llvm-base-3.0.0.0/ghc-7.0.3/libHSllvm-base-3.0.0.0.a(Core.o): In function `sdl3_info':
(.text+0x16ec4): undefined reference to `LLVMDeleteTypeName'
/home/karl/.cabal/lib/llvm-base-3.0.0.0/ghc-7.0.3/libHSllvm-base-3.0.0.0.a(Core.o): In function `sdlU_info':
(.text+0x16f8d): undefined reference to `LLVMAddTypeName'
/home/karl/.cabal/lib/llvm-base-3.0.0.0/ghc-7.0.3/libHSllvm-base-3.0.0.0.a(Core.o): In function `seTF_info':
(.text+0x1ce7e): undefined reference to `LLVMOpaqueType'
collect2: ld returned 1 exit status

UPDATE:

I was able to "fix" the problem by editing LLVM/FFI/Core.hsc to remove the offending foreign imports. I do not know whether this is the correct thing to do. Should I submit a patch or something?

cbits/extra.cpp won't compile

I posted this on the haskell-llvm mailing list; sorry if this constitutes a sort of cross-post. Perhaps github is the right place for it.

I have the following environment:

OS X 10.6.8
Haskell Platform 2011.4.0.0 64bit

When I try to install llvm via cabal, the install craps out on the compile of cbits/extra.cpp. Here is the message from 'cabal --verbose install llvm':

creating dist/build
/usr/bin/ghc -Idist/build -I/usr/local/include -Iinclude -package-id base-4.3.1.0-239d76b73f466dc120129098b3472858 -package-id bytestring-0.9.1.10-5bb17614aed376ea31b721a9272770b1 -package-id containers-0.4.0.0-b4885363abca642443ccd842502a3b7e -package-id directory-1.1.0.0-1ea434899f49294b2eb2d1e1ba551982 -package-id mtl-2.0.1.0-5b7a9cce5565d8cc8721ba4f95becf1b -package-id process-1.0.1.5-3e412eee765d141be15796c32f22f7a3 -package-id type-level-0.2.4-4c0d7e812179112051217b829f42233d -optc-O2 -odir dist/build -c cbits/extra.cpp -prof
cbits/extra.cpp: In function ‘void LLVMAddStructRetPromotionPass(LLVMOpaquePassManager*)’:

cbits/extra.cpp:537:0:
error: ‘createStructRetPromotionPass’ was not declared in this scope

I know NOTHING about C++. I note that comments in extra.cpp claim the functions therein are not required but nice to have for python bindings, or some thing to that effect. If I just delete the reference to extra.cpp in llvm.cabal, it seems to finish ok.

Is this some problem on my system, or is there a bug? Can I go ahead and try out llvm with Haskell without extra.cpp, i.e. with it removed from llvm.cabal?

fixing Vector example in classic llvm bindings

The Vector example fails with:

llvm-vector: example/Vector.hs:94:9-60: Irrefutable pattern failed for pattern Data.Maybe.Just iovec'

The problem is that the function getModuleValues does not return the named function "vectest" although it was created before. This is caused by filterM isIntrinsic in Core.Util.getFunctions. It was introduced by 6182044

I wonder why the filter was added. Maybe not . isIntrinsic was meant?

Split llvm repository

I propose to split the repository such that there is one repository per Cabal package. This allows to set git tags synchronously to Cabal package versions and allows according branching. Another reason is that there are many forks of the high-level llvm interface and I cannot see, why one package should be coupled with llvm-base.
For this reason I also propose to rename llvm to llvm-fd, since it uses functional dependencies, where my forked package named llvm-tf uses type families. But maybe the rename should be in a separate ticket.

Documentation?

What are the plans for documenting this library? It's not easy to grok by just reading through the comments alone. Following something like this guide, it's hard for me to understand what the translation to these bindings would be. It would be great to have a quickstart tutorial that's a little more expansive than augustss's blog post, and maybe something that explains the new types that are introduced in the code.

replace mtl by transformers

After our last discussion in the mailing list I have replaced mtl by transformers in llvm-tf.
I propose to do the same replacement in 'llvm', too.
I have prepared a commit for this purpose, that you may simply pull in:
http://code.haskell.org/~thielema/llvm-pull/transformers/

'transformers' does not need any language extensions and does not export identifiers from Control.Monad and other 'base' modules.

PtrSize

Is there any reason why type PtrSize = D32 on both 32-bit and 64-bit systems. If none shuldn't it be type PtrSize = D64 on 64-bit systems instead ?!

"error: invalid suffix "svn" on integer constant" when installing llvm-base

On some Ubuntu installations I can install llvm-base just fine, on others I can't. My full log can be found here.

I strongly suspect it is because I am building my own llvm from the source. It claims to be of version 3.1svn. Somehow, that svn is not cleaned from the constants, is what I am suspecting.

$ llc -version
LLVM (http://llvm.org/):
  LLVM version 3.1svn

I have no idea why this is 3.1svn, and on my other pc, it's 3.1, I compiled them from the same archives.

adding support for generating code that uses ghc calling convention

it looks like it'd be quite possible to generate code that respects the ghc calling convention, and perhaps provide a safe wrapper around running the code. (while also evading the c ffi overheads!). Which would also make it easier to generate fast calling convention code for ghc at runtime! (something that matters for me)

It might require writing a CMM (c minus minus ) shim or something, but I'm happy to look into it. And it looks like it'd be relatively sane to do for 7.6, and downright easy once ghc 7.8 stabilizes.

If i can sort it out and have it sanely working, would this be something that the maintainers would be open to merging in / helping maintain? (i think the code complexity for doing so won't be that high, and only 1-2 unsafe coerces may be needed internally :) )

any feedback / thoughts would be appreciated.

No Vector instance for generic.

Hopefully the code below is self explanatory. Due to a lack on a Vector Generic instance, I cannot use simpleFunction on g. I also cannot see how to use fromVector.

{-# LANGUAGE DataKinds,ScopedTypeVariables #-}

import Data.TypeLevel.Num (D8)
import LLVM.Core
import LLVM.Util.Loop
import LLVM.Util.File
import LLVM.ExecutionEngine

f ::  Value Float -> Value Float -> CodeGenFunction r (Value Float)
f = add

alterValue :: Value Float -> Value (Vector D8 Float) -> CodeGenFunction r (Value (Vector D8 Float))
alterValue x = mapVector (f x)

g :: CodeGenModule (Function (Float -> Vector D8 Float -> IO (Vector D8 Float)))
g = do
  f <- createNamedFunction ExternalLinkage "g" $ \x img -> do
         result <- alterValue x img
         ret result
  return f

myVec :: Vector D8 Float
myVec = toVector (45,89,190,251,25,91,11,23)

main :: IO ()
main = do
  writeCodeGenModule "my_func.bc" g

  -- I'd also like to use `g` in LLVM's JIT.
  -- So, I'd like to pass `myVec` and 3 to `g`.

  -- Initialize jitter
  initializeNativeTarget

  -- I get stuck here:
  unwrappedIOf <- simpleFunction g

{-
No instance for (Generic (Vector D8 Float))
      arising from a use of `simpleFunction'
-}

  -- This is due to a lack of a Vector instance for Generic.
  -- OK, but now I'm not sure how to do what I'd like to do:
  -- I'd like apply float 3 and vector `myVec` to g in the JIT.
  -- Then, I'd like to convert the vector returned by `g`.
  -- There are no examples in the llvm github with how to use
  -- the `toVector` and `fromVector`, or how to extract values
  -- from vectors.

Examples segfault on Windows

When running on windows with LLVM 3.2 built under 32-bit mingw, all examples fail with the message Segmentation fault/access violation in generated code

Split llvm-base package

I propose to split the llvm-base package into a low-level llvm-ffi package and a mid-level package named llvm-mid or llvm-wrapper. The mid-level interface adds the mtl dependency and is more experimental. The low-level interface should be rather canonical, but needs the difficult configuration process, the HSC preprocessor, but it does not need mtl with functional dependencies. Thus the low-level interface might even run on Haskell compilers without many extensions like JHC.
If the packages are split, they shall also be in separate repositories.

Deprecate ModuleProvider

LLVM has deprecated the ModuleProvider wrappers quite some time ago. I think we should follow suit and do the same.

This patch 44ddf8a shows what a complete removal would look like.

LLVM 3.4 compatibility

Hi,

Debian wants to make LLVM 3.4 the standard, and it seems that llvm-base needs to be updated to that. Is there an ETA for an updated version of llvm-base?

Thanks,
Joachim

Multiple issues compiling llvm with ghc 7.8.2

I was working on another package that required use of ghc 7.8 features but also depended on llvm. In attempting to compile llvm I ran into several issues. The experience may be helpful to others. Taking things in the order that they occurred:

llvm-base

LLVM/ST.hs:535:15:
    Could not deduce (MonadMG m0)
      arising from the ambiguity check for ‘runCodeGen’
    from the context (Monad (m c s), MonadMG m)
      bound by the type signature for
                 runCodeGen :: (Monad (m c s), MonadMG m) =>
                               STValue c s -> CodeGen c s a -> ModuleGen c s a
      at LLVM/ST.hs:(535,15)-(536,61)
    The type variable ‘m0’ is ambiguous
    In the ambiguity check for:
      forall c s a (m :: * -> * -> * -> *).
      (Monad (m c s), MonadMG m) =>
      STValue c s -> CodeGen c s a -> ModuleGen c s a
    To defer the ambiguity check to use sites, enable AllowAmbiguousTypes
    In the type signature for ‘runCodeGen’:
      runCodeGen :: (Monad (m c s), MonadMG m) =>
                    STValue c s -> CodeGen c s a -> ModuleGen c s a

Following the suggestion to enable the AllowAmbiguousTypes extension allowed successful compilation and installation of llvm-base.

type-level

llvm depends on type-level. The type-level package will not compile with ghc 7.8.2 due to stricter checking of coverage in instance declarations. The problem is exemplified by:

src/Data/TypeLevel/Num/Ops.hs:90:10:                                                                                                                                          
    Illegal instance declaration for ‘Succ' (x, x) (x, x) D0 D0 True’                                                                                                         
      The liberal coverage condition fails in class ‘Succ'’                                                                                                                   
        for functional dependency: ‘yh yl yz -> xh xl’                                                                                                                        
      Reason: lhs types ‘D0’, ‘D0’, ‘True’                                                                                                                                    
        do not jointly determine rhs types ‘(x, x)’, ‘(x, x)’                                                                                                                 
    In the instance declaration for ‘Succ' (x, x) (x, x) D0 D0 True’     

Similar Illegal instance errors occur on lines 254, 255, 256, 266, and 336 of Ops.hs. As a workaround, built a version of Ops.hs that simply did not have these instances declared -- it is not clear to me how to really fix the problem. llvm seems not to depend on any of these instances, but it is certainly not a general solution. I'll file a separate issue report for type-level, but if you just want to get llvm working, the workaround appears to be sufficient. Ops.h also requires the AllowAmbiguousTypes extension to be enabled.

llvm itself

llvm also has illegal instance problems:

LLVM/Util/Arithmetic.hs:250:10:
    Illegal instance declaration for
      ‘ArithFunction (CodeGenFunction r a) (CodeGenFunction r ())’
      The liberal coverage condition fails in class ‘ArithFunction’
        for functional dependency: ‘b -> a’
      Reason: lhs type ‘CodeGenFunction r ()’
        does not determine rhs type ‘CodeGenFunction r a’
    In the instance declaration for
      ‘ArithFunction (CodeGenFunction r a) (CodeGenFunction r ())’

Again non knowing what else to do, I simply removed the problematic instance declarations -- on lines 250, 253, 280 and 286 of Arithmetic.hs. My use of LLVM did not require any of them, but once again it's only a workaround and not a fix.

install fails due to missing libraries

Installation fails due to the following libraries missing:
-lLLVMXCoreAsmPrinter
-lLLVMSystemZAsmPrinter
-lLLVMSparcAsmPrinter
-lLLVMPIC16AsmPrinter
-lLLVMPIC16CodeGen
-lLLVMPIC16Info
-lLLVMMSIL
-lLLVMMSILInfo
-lLLVMMipsAsmPrinter
-lLLVMDebugger
-lLLVMCellSPUAsmPrinter
-lLLVMBlackfinAsmPrinter
-lLLVMAlphaAsmPrinter
-lLLVMSystem

These aren't found in LLVM version 2.9 and trunk. Some of them are in 2.8 but not all.
OS: Windows 7 (64-bit) with MinGW+MSYS.

Can MonadFix help eliminate need for newX/defineX split?

I'm just starting to explore the module, so not sure it makes sense in this case, but I know it was the answer for me when I encountered a similar API design problem. GHCs DoRec extension lets you do things like this for monads with a MonadFix instance, like IO:

do rec a <- somethingWith b
       b <- somethingWith a
       c <- foo c
    etc

llvm/Analysis/DomPrinter.h: No such file or directory

So I'm trying to install llvm-0.10.0.1 using cabal and I'm running into this issue:
llvm/Analysis/DomPrinter.h: No such file or directory

Looking into my llvm-2.6 shows that DomPrinter.h does not exist at that location. It does however exist in younger llvm releases.

The reason I'm doing this is so I can install Hydra which allegedly depends on llvm 2.6, according to its readme, and (this) llvm-0.10.0.1 according to the Hydra cabal manifest.

DomPrinter is imported at cbits/extra.cpp:71:38

What is at wrong here? I'm figuratively tearing my hair.

unsafe use of pointer in LLVM.Core.Util.constVector

I found the following code in LLVM.Core.Util.constVector:

withArrayLen xs $ \ len ptr ->
    return $ FFI.constVector ptr (fromIntegral len)

I think this won't work reliably, since "ptr" is only valid within withArrayLen and FFI.constVector might be run at any time after withArrayLen finished. I think it is wrong to define FFI.constVector without IO, since this suggests that you can run it somewhen in the future.
This problem might be the cause for some crashes and it occurs at other places as well.

Bool corruption across extern and FFI calls

The LLVM bindings map the Bool type to an i1. This works fine (though perhaps a bit slow) within LLVM generated code but does not work with externFunction mappings or foreign imports in Haskell. In this example ret (valueOf False) is compiled to xor $al, leaving trash in upper bits of $rax. I propose mapping Bool to a i32 or i64 instead of an i1.

define i1 @_fun1() {
_L1:
  %0 = call i64 @malloc(i64 1)
  ret i1 false
}

>>> True

define i1 @_fun2() {
_L1:
  ret i1 false
}

>>> False
    .section    __TEXT,__text,regular,pure_instructions
    .globl  __fun1
    .align  4, 0x90
__fun1:                                 ## @_fun1
Ltmp1:
    .cfi_startproc
## BB#0:                                ## %_L1
    pushq   %rax
Ltmp2:
    .cfi_def_cfa_offset 16
    movl    $1, %edi
    callq   _malloc
    xorb    %al, %al
    popq    %rdx
    ret
Ltmp3:
    .cfi_endproc
Leh_func_end0:

    .globl  __fun2
    .align  4, 0x90
__fun2:                                 ## @_fun2
Ltmp4:
    .cfi_startproc
## BB#0:                                ## %_L1
    xorb    %al, %al
    ret
Ltmp5:
    .cfi_endproc
Leh_func_end1:


.subsections_via_symbols
import Control.Monad (liftM2)
import Control.Monad.Trans (liftIO)
import Control.Monad.Trans.Resource
import Data.Int
import Foreign.Ptr
import LLVM.Core
import LLVM.ExecutionEngine
import LLVM.FFI.Support (disablePrettyStackTrace)

emitFunctionBroken
  :: CodeGenModule (Function (IO Bool))
emitFunctionBroken = createFunction ExternalLinkage $ do
  m <- externFunction "malloc"
  call (m :: Function (Int64 -> IO Int64)) (valueOf 1)
  ret (valueOf False)

emitFunctionWorking
  :: CodeGenModule (Function (IO Bool))
emitFunctionWorking = createFunction ExternalLinkage $
  ret (valueOf False)

foreign import ccall unsafe "dynamic" mkFun :: FunPtr (IO Bool) -> (IO Bool)

main :: IO ()
main = do
  -- boot up LLVM
  initializeNativeTarget

  runResourceT $ do
    m <- liftIO $ newModule
    (b, w) <- liftIO $ defineModule m $
      liftM2 (,) emitFunctionBroken emitFunctionWorking
    (_, ee) <- allocate (createExecutionEngine m) destroyExecutionEngine
    bfun <- liftIO $ fmap mkFun (getPointerToFunction ee b)
    wfun <- liftIO $ fmap mkFun (getPointerToFunction ee w)
    liftIO $ do
      dumpValue b
      print =<< bfun

      dumpValue w
      print =<< wfun

Global var or global array containing ptr to function

In my program in need to create global variables and/or arrays containing pointers to internally linked functions.

As I see from documentation at http://hackage.haskell.org/packages/archive/llvm/0.9.1.2/doc/html/ when defining new global variable/array I need to provide value(s) of type 'ConstValue a', but 'Function a' (which I suppose represents pointer to the function itself) is defined as 'Value (Ptr a)', so it is a non-constant pointer.

Is there any solution for this problem? I think it is valid usecase, as it is possible to do so either when using other bindings to LLVM or when simply writing code in C!

What is the trick to install this package?

I have tried it with a self-built llvm, both the configure and cmake way, I have tried version 2.8 and 2.9, I have tried the ubuntu packages llvm-dev. But with every of these installs, cabal install llvm replied the same way:

checking llvm-c/Core.h usability... yes
checking llvm-c/Core.h presence... yes
checking for llvm-c/Core.h... yes
checking llvm/Support/DynamicLibrary.h usability... yes
checking llvm/Support/DynamicLibrary.h presence... yes
checking for llvm/Support/DynamicLibrary.h... yes
checking for LLVMModuleCreateWithName in -lLLVMCore... no
checking for LLVMModuleCreateWithName in -lLLVMCore... no
configure: error: could not find LLVM C bindings
cabal: Error: some packages failed to install:
llvm-0.10.0.1 failed during the configure step. The exception was:
ExitFailure 1

The funny detail is, I've made it work on my home-desktop just recently, with a self-built llvm 2.9. But I have no idea how.

What is the magic trick to get this package to install?

Expose ExecutionEngine

The ExecutionEngine has been restricted to the land of FFI for quite some time. The preferred route for dealing with an ExecutionEngine has been through the EngineAccess monad. This is historically significant because LLVM previously allowed a single ExecutionEngine per process, a limit that has since been lifted. I think it's time to change this. I have an old patch 1fce8ae sitting around that totally removes the EngineAccess related goo. This might be a bit extreme, so I'm wondering if anyone else here has opinions on the matter. Should we:

  • Remove EngineAccess totally and replace it's usage with ExecutionEngine (per the referenced patch)
  • Add a second set of functions to work with ExecutionEngine, and optionally mark the EngineAccess bits as deprecated.

adding support for llvm 3.3

I'll look into this, though i may need some baby sitting/help. (since LLVM 3.3 is in RC state now, would be nice to have the bindings ready come that release. )

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.