Don Stewart <dons <at> galois.com> writes: > > 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 _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
