Don Stewart
joseph.bruce:
Hi,
I have a Haskell library that I want to make available via FFI to C programmers on my project team. I read this thread (http://thread.gmane.org/gmane.comp.lang.haskell.cafe/21447) which had some interesting ideas, but they seemed unresolved. Or maybe it answers my question but I don't understand it.
Is there a way I can package (ghc-)compiled Haskell code into a statically-linked library and not force the C programmers to include headers and libraries that they have no knowledge of and undefine a seemingly endless list of preprocessor symbols (run ghc with the verbose flag and look at the calls to gcc)? Can this process be automated?
Yes, check the FFI documentation for the main story.
In short, build the Haskell code with cabal, with your foreign export Haskell functions in the cbits. That bundle can then be linked against C code.
You do need to link your app against libHSrts.a and libHSbase.a (and other libs you use), but assuming you foreign export, the code to call will look just like normal C stuff.
Thanks Don. I finally got back to this. I hadn't looked at CABAL before. It's a very useful tool and met all my library-forming needs. That's only half my problem though. I'm trying to make the use of this Haskell code as transparent as possible to the C programmers on the team. Telling them about the Haskell base libraries dependency or distributing those libraries with my code is not too bad, but the list of -u flags that the linker needs is brutal. Is there a way to avoid it, or embed it in the package? Ex (using ghc-6.8.2 -v): ... gcc -v -o primes Primes.o ./Primes_stub.o hs_primes_wrapper.o cprimes.c -Bc:\ghc\ghc-6.8.2\gcc-lib/ -DDONT_WANT_WIN32_DLL_SUPPORT -Lc:/ghc/ghc-6.8.2/lib\base-3.0.1.0 -Lc:/ghc/ghc-6.8.2 -Lc:/ghc/ghc-6.8.2/gcc-lib -lHSbase-3.0.1.0 -lwsock32 -lmsvcrt -lkernel32 -luser32 -lshell32 -lHSrts -lm -lgmp -lwsock32 -u _base_GHCziBase_Izh_static_info -u _base_GHCziBase_Czh_static_info -u _base_GHCziFloat_Fzh_static_info -u _base_GHCziFloat_Dzh_static_info -u _base_GHCziPtr_Ptr_static_info -u _base_GHCziWord_Wzh_static_info -u _base_GHCziInt_I8zh_static_info -u _base_GHCziInt_I16zh_static_info -u _base_GHCziInt_I32zh_static_info -u _base_GHCziInt_I64zh_static_info -u _base_GHCziWord_W8zh_static_info -u _base_GHCziWord_W16zh_static_info -u _base_GHCziWord_W32zh_static_info -u _base_GHCziWord_W64zh_static_info -u _base_GHCziStable_StablePtr_static_info -u _base_GHCziBase_Izh_con_info -u _base_GHCziBase_Czh_con_info -u _base_GHCziFloat_Fzh_con_info -u _base_GHCziFloat_Dzh_con_info -u _base_GHCziPtr_Ptr_con_info -u _base_GHCziPtr_FunPtr_con_info -u _base_GHCziStable_StablePtr_con_info -u _base_GHCziBase_False_closure -u _base_GHCziBase_True_closure -u _base_GHCziPack_unpackCString_closure -u _base_GHCziIOBase_stackOverflow_closure -u _base_GHCziIOBase_heapOverflow_closure -u _base_GHCziIOBase_NonTermination_closure -u _base_GHCziIOBase_BlockedOnDeadMVar_closure -u _base_GHCziIOBase_BlockedIndefinitely_closure -u _base_GHCziIOBase_Deadlock_closure -u _base_GHCziIOBase_NestedAtomically_closure -u _base_GHCziWeak_runFinalizzerBatch_closure -u _base_GHCziConc_ensureIOManagerIsRunning_closure ... This particular example is a build on a windows system and makes use of the .o's directly and not the .a I create, but those are of no consequence as this is ultimately a linking issue, not a compilation issue. I don't know what these -u's are for, but I know that if I take them out, the linker fails. They do change from one system to another (this list fails with the linker on RHEL 5). But right now my solution for the C programmers is a make file with $haskell_undefine_flags = <that mess up there>, and I'd prefer something more elegant and less system dependent. I am willing to accept that there is no good way around it, but perhaps someone has dealt with this issue before. Any help? Thanks. Joe