[Haskell-cafe] Re: Exporting Haskell Libraries to C Programmers

[Bruce, Joseph R (Joe)]

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