chetant / libclang Goto Github PK

To produce good results libclang relies on the presence of a set of header files that are normally distributed with it. We need to also distribute those header files in LibClang and provide the programmer with access to their location.

I'm using a wrapper to avoid the Alloc requirement for visitChildren:

import qualified Control.Concurrent as CC

visitChildren' :: Cursor -> ChildVisitor a -> Maybe a -> IO (Maybe a, Bool)
visitChildren' cursor0 userVisitor userData0 = do
  m <- CC.newMVar userData0
  let cheaterVisitor cursor parent _ = do
        currentUserData <- CC.takeMVar m
        (newUserData,newUserRetCode) <- userVisitor cursor parent currentUserData
        CC.putMVar m newUserData
        return (Nothing :: Maybe Int, newUserRetCode)
  (_,finalRetCode) <- C.visitChildren cursor0 cheaterVisitor Nothing
  finalData <- CC.takeMVar m
  return (finalData, finalRetCode)

Is this a reasonable thing to do? I don't see a reason to pass the data pointer through the c library when it can be done in haskell.

Hi there, I'm using Linux Mint (Ubuntu derivat) and want to install libClang with Cabal.

The problem is, that I always get the message: "requires ffi" and then it stops.

I have installed on my system:

• Haskel-Platform 2010.1.0.0.1
• libffi5
• libffi-dev

what is missing?

Heyo

I installed ghc 8.0.1 and cabal 1.25 and no matter how I try to build it it doesn't compile. When trying to compile the Setup.hs from the master branch is says:

Setup.hs:272:84: error:
Not in scope: type constructor or class ‘LibraryName’

When I try installing it with cabal the error message is:

src/ErrMonad.lhs:42:10: error:
• No instance for (Applicative (ErrM a))
arising from the superclasses of an instance declaration
• In the instance declaration for ‘Monad (ErrM a)’
cabal: Leaving directory '/tmp/cabal-tmp-4902/greencard-3.0.4.2'
cabal: Error: some packages failed to install:
LibClang-0.1.0-JWbxC2bC4YSHhNKAX6WBhy depends on LibClang-0.1.0 which failed
to install.
greencard-3.0.4.2-CIO3I1N7VPbLpRLRYOkKRW failed during the building phase. The
exception was:
ExitFailure 1

Thanks for the Help

I just built the latest llvm3.4 branch, and when I tried to compile my program with ghc --make MyLibClangApp.hs I got this error:

Linking MyLibClangApp ...
/usr/bin/ld: /home/ghorn/hslibs/LibClang/build/out/lib/libLLVMSupport.a(Mutex.o): undefined reference to symbol 'pthread_mutexattr_settype@@GLIBC_2.2.5'
/lib/x86_64-linux-gnu/libpthread.so.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status

I do have the pthread_mutexattr_settype symbol:

$ nm /lib/x86_64-linux-gnu/libpthread.so.0 | grep -i pthread_mutexattr_settype
000000000000af40 T __pthread_mutexattr_settype
000000000000af40 T pthread_mutexattr_settype

but it doesn't have @@GLIBC_2.2.5 appended to it.

Do you have any idea what this might be about? I'm on Debian Sid, 64 bit btw

The linked code segfaults for even the utmost trivial C++ code (e.g. int main function, returning 0)

https://gist.github.com/apriori/0527c9d03b03fc5f5e10

This library should remain a thin layer over the C libclang API, but there are definitely some cases where things can be made a bit easier to use, and everything needs to be documented. Examples:

• Some thought needs to be given to what should be exported by default in the top-level Clang module.
• It'd be good to go over the names of all the functions and make sure they're consistent. There are some functions that might be better off in a different module.
• If there are places where we can reduce the need to manually write out the ClangApp phantom type parameter, that'd be nice.
• Everything needs to be documented.

Every project I've seen that uses libclang ends up embedding it as a submodule. Using the system libclang makes life much harder for end users unless you want to avoid using any feature introduced by newer versions of libclang. Even then an embedded version of libclang is preferable since IIRC, on OS X the system libclang is stripped and you can't link against it.

(This is not new, I'm posting here to document the status)

The hackage version of greencard doesn't build on 7.8, which blocks people from cabal install LibClang. Their github version works fine though.

see sof/greencard#1

I emailed the greencard devs yesterday. If they don't respond we can try emailing the ghc-users mailing list next.

I pulled master and ran the child visitor test scripts.

The C version seems to work fine, but I get Segmentation fault (core dumped) when I run any file using the Haskell version like: > Test_ChildVisitor "test.h"
-deech

Installing libclang using cabal fails for me. Here are the messages I received:

$ cabal install libclang
Resolving dependencies...
Configuring LibClang-0.0.2...
configure: WARNING: unrecognized options: --with-compiler, --with-gcc
checking for llvm-config... yes
checking for gcc... 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... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking clang-c/Index.h usability... yes
checking clang-c/Index.h presence... yes
checking for clang-c/Index.h... yes
configure: creating ./config.status
config.status: creating LibClang.buildinfo
configure: WARNING: unrecognized options: --with-compiler, --with-gcc
Preprocessing library LibClang-0.0.2...
Warning: unable to find Foreign.GreenCard along the import path:
using built-in defaults instead.
greencard: user error ("src/Clang/FFI.gc", proc. spec "clang_getFileTime", line 100:
Don't know how to unmarshall (word64 res1)

)
cabal: Error: some packages failed to install:
LibClang-0.0.2 failed during the building phase. The exception was:
ExitFailure 1

Here is the other information I have that I believe may be relevant:

$ type llvm-config
llvm-config is /opt/local/bin/llvm-config
$ llvm-config --version
2.9
$ uname -a
Darwin thomas 10.7.0 Darwin Kernel Version 10.7.0: Sat Jan 29 15:16:10 PST 2011; root:xnu-1504.9.37~1/RELEASE_X86_64 x86_64
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.0.2
$ cabal --version
cabal-install version 0.10.2
using version 1.10.1.0 of the Cabal library

Any guidance for how to proceed would be appreciated.

There are still a few types in FFI.gc that are manipulated unsafely. Before pushing anything to Hackage everything needs to be cleaned up.

I have a simple Stack project which references LibClang-3.4.0 via an extra-deps entry in stack.yaml. Attempts to build this project fail due to the following compilation error in LibClang:

    Preprocessing library LibClang-3.4.0...
    [ 1 of 25] Compiling Clang.Internal.FFIConstants ( .stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/Clang/Internal/FFIConstants.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/Clang/Internal/FFIConstants.o )
    [ 2 of 25] Compiling Paths_LibClang   ( .stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/autogen/Paths_LibClang.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/Paths_LibClang.o )
    [ 3 of 25] Compiling Clang.Internal.BitFlags ( src/Clang/Internal/BitFlags.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/Clang/Internal/BitFlags.o )
    [ 4 of 25] Compiling Clang.Internal.Monad ( src/Clang/Internal/Monad.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/Clang/Internal/Monad.o )
    [ 5 of 25] Compiling Clang.Internal.FFI ( .stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/Clang/Internal/FFI.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/Clang/Internal/FFI.o )
    [ 6 of 25] Compiling Clang.Index      ( src/Clang/Index.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/Clang/Index.o )
    [ 7 of 25] Compiling Clang.TranslationUnit ( src/Clang/TranslationUnit.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/Clang/TranslationUnit.o )
    [ 8 of 25] Compiling Clang.Internal.Comment ( src/Clang/Internal/Comment.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/Clang/Internal/Comment.o )
    [ 9 of 25] Compiling Clang.Comment    ( src/Clang/Comment.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/Clang/Comment.o )
    [10 of 25] Compiling Clang.Completion ( src/Clang/Completion.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/Clang/Completion.o )
    [11 of 25] Compiling Clang.Cursor     ( src/Clang/Cursor.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/Clang/Cursor.o )
    [12 of 25] Compiling Clang.Debug      ( src/Clang/Debug.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/Clang/Debug.o )
    [13 of 25] Compiling Clang.Diagnostic ( src/Clang/Diagnostic.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/Clang/Diagnostic.o )
    [14 of 25] Compiling Clang.File       ( src/Clang/File.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/Clang/File.o )
    [15 of 25] Compiling Clang.Location   ( src/Clang/Location.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/Clang/Location.o )
    [16 of 25] Compiling Clang.Module     ( src/Clang/Module.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/Clang/Module.o )
    [17 of 25] Compiling Clang.Range      ( src/Clang/Range.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/Clang/Range.o )
    [18 of 25] Compiling Clang.Remapping  ( src/Clang/Remapping.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/Clang/Remapping.o )
    [19 of 25] Compiling Clang.String     ( src/Clang/String.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/Clang/String.o )
    [20 of 25] Compiling Clang.Token      ( src/Clang/Token.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/Clang/Token.o )
    [21 of 25] Compiling Clang.Type       ( src/Clang/Type.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/Clang/Type.o )
    [22 of 25] Compiling Clang.UnsavedFile ( src/Clang/UnsavedFile.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/Clang/UnsavedFile.o )
    [23 of 25] Compiling Clang.USR        ( src/Clang/USR.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/Clang/USR.o )
    [24 of 25] Compiling Clang.Version    ( src/Clang/Version.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/Clang/Version.o )
    [25 of 25] Compiling Clang            ( src/Clang.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/Clang.o )
    <command line>: does not exist: dist/build/Clang/Internal/FFI.chs.c

Right now the llvm and clang submodules are considerably behind HEAD in their respective upstream repos. I'd like to update them both. The llvm submodule can use the official github mirror instead of my own, and my clang mirror should be rebased. (I'm working to get everything upstreamed ASAP, but it hasn't happened yet.)

Version 0.1.0 from hackage gives the error

src/Clang/FFI_stub_ffi.c:411:12:
error: ‘CXTranslationUnit_CXXPrecompiledPreamble’ undeclared (first use in this function)
do {res1=CXTranslationUnit_CXXPrecompiledPreamble;

whereas the master branch on github builds successfully. If I diff FFI_stub_ffi.c between the two, there are indeed differences - I would expect them to match..

I have ghc 7.6.3 and clang version 3.3

Hi,
I would like to use Libclang it depends on Greencard which does not build on the latest GHC (7.10.x). I have made attempts to contact the maintainer but haven't heard back. Furthermore it seems like a dead project anyway. To that end I am working on converting FFI.gc to FFI.chs so that c2hs , which is being actively developed, is used instead of Greencard. Are you willing to merge in such a change when I'm done?

Bindings to these functions:

int clang_Cursor_getNumArguments(CXCursor C);
CXCursor clang_Cursor_getArgument(CXCursor C, unsigned i);

would be handy. They should probably be wrapped inside one function getArguemnts. I can try and add this myself if you like.

Currently master/llvm3.3/llvm3.4 are much more different than the llvm version. Also, since llvm/clang is now built with LibClang, the llvm version is not as important and LibClang should "Just Work".

I propose merging llvm3.4 to master, and deleting llvm3.3. Though maybe we should wait until #33 is fixed so that master doesn't get a regression.

Any plans for a new release in the upcoming weeks? I'm developing a project in tandem and would like to depend on the current HEAD.

We're missing bindings to a good number of the newer additions to libclang.

when i import Clang and want to use it i get the following error:
unknown symbol _clang_toggleCrashRecovery (C:\Users\Foo\AppData\Roadming\cabal\LibClang-0.0.9\ghc-7.0.3\HSLibClang-0.0.9.o)

See the following gist:

https://gist.github.com/apriori/871b01b9a7a774ba22f4

I assume its another FFI error like #47. Btw, if you could give me some pointers on how you guys actually debug this to get the exact location of the error in the FFI, I would fix stuff like this myself and create a pull request.

The Haddocks for release 3.4.0 (http://hackage.haskell.org/package/LibClang-3.4.0) have not yet been built on Hackage. Maybe manually upload using https://gist.github.com/5outh/ca9bce3e112eb2eed98c?

I rebuild ghc, haskell-plattform and even LibClang from source but everytime it gives me the same error:

Setup.hs:17:8:
    Could not find module `Distribution.Simple.Program.Find'
    Perhaps you meant
      Distribution.Simple.Program.Ld (from Cabal-1.16.0)
      Distribution.Simple.Program.Run (from Cabal-1.16.0)
      Distribution.Simple.Program.Ar (from Cabal-1.16.0)
    Use -v to see a list of the files searched for.

Do I have to fix something in the dependencies?

Thanks

Multiple errors:

Ambiguous occurrence `unsafePerformIO'
It could refer to either `Foreign.GreenCard.unsafePerformIO',
                         imported from `Foreign.GreenCard' at dist/build/Clang/FFI.hs:171:1-24
                         (and originally defined in `Foreign')
                      or `System.IO.Unsafe.unsafePerformIO',
                         imported from `System.IO.Unsafe' at dist/build/Clang/FFI.hs:176:25-39
                         (and originally defined in `GHC.IO')

If I understood correcty, you use LLVM/CLang 3.4 without any significant patches. An option to use out-of-tree libraries would be great -- to reduce compilation times of clean tree and to re-use existing libraries from the system -- e.g. on Linux where they are provided already by package managers. I could have overlooked some reason because of which you build them in-tree -- I'm sorry if this is the case.

@chetant - It looks like only you can set up Travis CI, alas. (I don't have access to the admin panel.) @ghorn has done as much of the initial setup work as I think we can do on the llvm3.4 branch.

Could you please set up Travis CI for this repo? Directions are here:

http://about.travis-ci.org/docs/user/getting-started/

i want to compile the following test program:
import Clang
main = do
putStrLn "hi"

now i compile with: ghc --make test.hs

then i get teh following error:
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 toclang_toggleCrashRecovery'
collect2: ld returned 1 exit status

EDIT: perhaps here a interesting output at the end of cabal install libClang

[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

: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...
Installing library in /home/bart/.cabal/lib/LibClang-0.0.9/ghc-7.0.3
Registering LibClang-0.0.9...

As discussed in b98dbf9, apparently LibClang only works in ghci on osx if it is built statically. I don't understand that, but if it works, it works. On linux, it only works in ghci if it's build shared. I used to use --configure-option=--enable-llvm-shared=LLVMSHAREDLIB but now that llvm is a submodule i don't think that works anymore.

Some name strings in the test have the first four chars replaced with '\0' (null) chars.
Here's the diff from the C and Haskell version outputs.

58c58
< Name:mode_t, Kind:TypedefDecl

---
> Name:_t, Kind:TypedefDecl
143c143
< Name:_G_uint16_t, Kind:TypedefDecl

---
> Name:int16_t, Kind:TypedefDecl
344c344
< Name:clang_equalCursors(CXCursor, CXCursor), Kind:FunctionDecl

---
> Name:g_equalCursors(CXCursor, CXCursor), Kind:FunctionDecl
420c420
< Name:clang_getSpecializedCursorTemplate(CXCursor), Kind:FunctionDecl

---
> Name:g_getSpecializedCursorTemplate(CXCursor), Kind:FunctionDecl
455c455
< Name:clang_defaultCodeCompleteOptions(), Kind:FunctionDecl

---
> Name:g_defaultCodeCompleteOptions, Kind:FunctionDecl

have the problem that cabal install (in mingw) can't find clang-c/Index.h.
i want to set it via -I but dont know why i get the message:
unrecognized option

Hi,
I guess this release doesn't build LLVM statically like it used to. A big advantage was that resulting binaries weren't dependent on the user having installed LLVM. Would a PR that used a flag to trigger the old functionality (static build, not bundled libraries) be welcome?

always i want to run cabal install libClang under archlinux i get:
the programm greencard is required but it could not be found.

but greencard was installed with cabal install before!

when i import Clang and want to run the script i get the error:
Loading package LibClang-0.0.9 ... can't load .so/.DLL for: LLVMSupport (Support.so: cannot open shared object file: No such file or directory)

what can I do?

Running the generated makefile in the test directory gets me this error:
gcc -std=gnu99 -I/usr/lib/llvm-3.1/include -DNDEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -g -O2 -fomit-frame-pointer -fPIC -L/usr/lib/llvm-3.1/lib -lpthread -lffi -ldl -lm -lLLVMAsmParser -lLLVMInstrumentation -lLLVMLinker -lLLVMArchive -lLLVMBitReader -lLLVMDebugInfo -lLLVMJIT -lLLVMipo -lLLVMVectorize -lLLVMBitWriter -lLLVMTableGen -lLLVMHexagonCodeGen -lLLVMHexagonAsmPrinter -lLLVMHexagonDesc -lLLVMHexagonInfo -lLLVMPTXCodeGen -lLLVMPTXDesc -lLLVMPTXInfo -lLLVMPTXAsmPrinter -lLLVMMBlazeAsmParser -lLLVMMBlazeDisassembler -lLLVMMBlazeCodeGen -lLLVMMBlazeDesc -lLLVMMBlazeInfo -lLLVMMBlazeAsmPrinter -lLLVMCppBackendCodeGen -lLLVMCppBackendInfo -lLLVMMSP430CodeGen -lLLVMMSP430Desc -lLLVMMSP430Info -lLLVMMSP430AsmPrinter -lLLVMXCoreCodeGen -lLLVMXCoreDesc -lLLVMXCoreInfo -lLLVMCellSPUCodeGen -lLLVMCellSPUDesc -lLLVMCellSPUInfo -lLLVMMipsCodeGen -lLLVMMipsDisassembler -lLLVMMipsAsmParser -lLLVMMipsDesc -lLLVMMipsInfo -lLLVMMipsAsmPrinter -lLLVMARMCodeGen -lLLVMARMDisassembler -lLLVMARMAsmParser -lLLVMARMDesc -lLLVMARMInfo -lLLVMARMAsmPrinter -lLLVMPowerPCCodeGen -lLLVMPowerPCDesc -lLLVMPowerPCInfo -lLLVMPowerPCAsmPrinter -lLLVMSparcCodeGen -lLLVMSparcDesc -lLLVMSparcInfo -lLLVMX86Disassembler -lLLVMX86CodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMX86AsmParser -lLLVMX86Desc -lLLVMX86Info -lLLVMX86AsmPrinter -lLLVMX86Utils -lLLVMMCDisassembler -lLLVMMCParser -lLLVMInterpreter -lLLVMCodeGen -lLLVMScalarOpts -lLLVMInstCombine -lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis -lLLVMMCJIT -lLLVMRuntimeDyld -lLLVMExecutionEngine -lLLVMTarget -lLLVMMC -lLLVMObject -lLLVMCore -lLLVMSupport -lclang -o Test_Diagnostics_c Test_Diagnostics.c
Test_Diagnostics.c: In function ‘main’:
Test_Diagnostics.c:6:3: warning: passing argument 3 of ‘clang_parseTranslationUnit’ from incompatible pointer type [enabled by default]
In file included from Test_Diagnostics.c:1:0:
/usr/include/clang-c/Index.h:987:34: note: expected ‘const char * const_’ but argument is of type ‘char *_’
/tmp/ccRAZlb7.o: In function main': /home/deech/Haskell/LibClang/test/Test_Diagnostics.c:5: undefined reference toclang_createIndex'
/home/deech/Haskell/LibClang/test/Test_Diagnostics.c:6: undefined reference to clang_parseTranslationUnit' /home/deech/Haskell/LibClang/test/Test_Diagnostics.c:8: undefined reference toclang_getNumDiagnostics'
/home/deech/Haskell/LibClang/test/Test_Diagnostics.c:10: undefined reference to clang_getNumDiagnostics' /home/deech/Haskell/LibClang/test/Test_Diagnostics.c:12: undefined reference toclang_getDiagnostic'
/home/deech/Haskell/LibClang/test/Test_Diagnostics.c:13: undefined reference to clang_defaultDiagnosticDisplayOptions' /home/deech/Haskell/LibClang/test/Test_Diagnostics.c:13: undefined reference toclang_formatDiagnostic'
/home/deech/Haskell/LibClang/test/Test_Diagnostics.c:14: undefined reference to clang_getCString' /home/deech/Haskell/LibClang/test/Test_Diagnostics.c:15: undefined reference toclang_disposeString'
/home/deech/Haskell/LibClang/test/Test_Diagnostics.c:18: undefined reference to clang_disposeTranslationUnit' /home/deech/Haskell/LibClang/test/Test_Diagnostics.c:19: undefined reference toclang_disposeIndex'
collect2: error: ld returned 1 exit status
make: *** [Test_Diagnostics_c] Error 1

The problem is that -lclang comes before the source file, removing lclang from the LDFLAGS list and changing the Makefile %_c target to:
$(CC) $(CFLAGS) $(LDFLAGS) -o $@ $< -lclang
solved the issue.
-deech

I've emailed the maintainer of greencard to try to get this fixed. It's trivial; it's just that catch is no longer exported in the Prelude and you need to use System.IO.Error.catchIOError instead.

I've been fixing it locally as a temporary workaround.

I just noticed that LLVM's configure script now has a --with-clang-resource-dir option, which we can set to the directory where we'll install LibClang. That will eliminate the need for my setClangResourcesPath patch, so I think we should switch to it.

I'm going to avoid this until we get the current issues with the build system sorted out, though, as I don't want to make merging any harder than it has to be.

There's some sample text in there that needs to be filled in properly. Also, if we copy in libclang's documentation, we need to update the license file appropriately.

createArLibArchive takes different arguments with cabal 1.20.

We could potentially fix this with an upper bound on the cabal version, but given that cabal 1.20 works on GHC 7.6.3 I'm inclined to update Setup.hs to work with the new version and bump our cabal lower bound.

I'll go ahead and do that, but I'll leave this open for a bit in case others want to chime in.

It makes sense to me that LibClang's version should track the LLVM version it builds with. For example, the upcoming release should be LibClang 3.4 since it works with LLVM 3.4.

The new build system looks much nicer, but it had to be backed out because of link failures on OS X. Linking of programs that use LibClang fails because of unresolved symbols from libstdc++.

In the old (now current again) Setup.hs, we fixed this problem by linking in libstdc++ a second time after the LLVM libraries, so that all of the symbols they needed would be caught.

It's not obvious to me how to deal with this when linking using the new ar-based technique.

@chetant, what do we need to do here? I don't actually understand what the ar-based technique is buying us, so I'm not sure if the best bet is just to remove it and revert to linking directly with the LLVM libraries, or to try to find a way to resolve this issue.

CXCursorKind and some of the other libclang enumerations contain "boundary" values indicating the first and last values of various types - e.g., CXCursor_FirstExpr and CXCursor_LastExpr. In idiomatic Haskell code these values wouldn't be part of the enumeration. I'm also concerned that keeping them in there might cause bugs since multiple enumeration values have the same numeric value. These values should be pulled out of the enumerations and made into regular values on the Haskell side.

There are a couple of non-boundary cases (e.g. CXCursor_GCCAsmStmt and CXCursor_AsmStmt) that also share numeric values, and we should handle them similarly.