[Haskell-cafe] Re: Export Haskell Libraries

[Dan Weston]

In the GHC docs:
http://www.haskell.org/ghc/docs/6.4.1/html/users_guide/sec-ffi-ghc.html#using-own-main

"There can be multiple calls to hs_init(), but each one should be 
matched by one (and only one) call to hs_exit()[8]."

What exactly happens with nested calls? Is there only one runtime 
created, with a simple counter to know which hs_exit should shut it 
down? If so, is there a way of having multiple interpreters open safely 
at the same time?

Or does each hs_init() create a new separate concurrent runtime (the 
preferable alternative)?

And what is the cost of creating and destructing the GHC runtime anyway?

Can the Haskell interpreter be in a Linux shared-object library, so long 
as I make sure to call hs_init() after loading and hs_exit() before 
unloading it? My experiments so far show this working flawlessly, but I 
vaguely remember an e-mail thread saying GHC couldn't be linked in 
dynamically.

Dan

Simon Marlow wrote:
> It seems that what you want is a standalone .a file that you can then 
> link into other programs without any special options.  In principle this 
> should be possible: you just need to include .o files for the RTS and 
> libraries, and fortunately we already have those (HSrts.o, HSbase.o 
> etc.) because they're needed by GHCi.  You won't need the -u options 
> because the whole base package will be linked in anyway.  I can't 
> immediately think of a reason this wouldn't work, but I could be wrong...
> 
> Cheers,
>     Simon
> 
> SevenThunders wrote:
>>
>> Duncan Coutts wrote:
>>>
>>>
>>> So it's easy if you link the system using ghc. If you want to link it
>>> all using gcc instead, yeah, that's a bit harder. You can see most of
>>> the flags ghc passes to gcc as they're just in the package configuration
>>> for the rts and base packages (ghc-pkg display rts / base). It should be
>>> fairly straightforward to generate a gnu linker script from all this
>>> that you could use with gcc when linking your whole system. By tucking
>>> the ghc flags away in a linker scrupt you will not terrify your fellow
>>> developers with all the odd -u flags.
>>>
>> That was my first thought and in fact I did write such a script.  The 
>> only
>> problem is
>> I'm afraid that the link stages for the software I have integrate to 
>> may be
>> rather complex
>> and I thought that maybe this would not be the best approach if there 
>> were
>> order dependencies
>> etc.  But maybe it's not so bad.  In the end I managed to capture all the
>> dependencies in CMake
>> so I'm hoping that will make it a little easier to do the final 
>> integration.
>>
>>
>>
>>> As for the issue of cabal putting generated files in a directory other
>>> than the source tree, you can tell cabal exactly which directory to use,
>>> so it's not that non-portable to go grubbing around in it to find the .o
>>> files you need to link into the archive file.
>>>
>> I saw a lot of options for places to put sources and targets, but I 
>> couldn't
>> quite
>> figure out how to configure it to place the object file output.  No doubt
>> it's there, I just couldn't
>> find it in the 45 min.s or so that I looked for it.
>>
>>
>>
>>> Alternatively you could just let cabal build the .a file. It can include
>>> externally generated .o files into the archive. Alternatively you can
>>> just use two .a files, keeping your other .o's in a separate file. Or
>>> you could even combine the two archives together as a later build step.
>>>
>> Yes, this would be an attractive approach I think.  Is it a matter of
>> passing the correct flags to ghc,
>>  Ghc-options:  -?
>> At first glance, looking at the basic tutorial it seemed like to build a
>> library one uses a line like
>> Exposed Modules: A B C
>> However I thought this would build Haskell only libraries.    Then 
>> there is
>> the business of merging libraries, which I suppose is done with ar and
>> ranlib  by extracting all the object files from one library and then 
>> adding
>> them back in to the other.  If it had to portable to windows as well I
>> wonder if this would work.
>>
>>
>>
>>
>>> Actually it's not too bad if you ignore all the 50 -u flags. Apart from
>>> that, the "single runtime library" you want is just three: HSbase,
>>> HSbase_cbits and HSrts. Those also depend on some system C libs: m, gmp,
>>> dl and rt.
>>>
>> running ghc -v for all my haskell code forced me to link to these 
>> libraries
>> ultimately:
>> HShaskell98 HSregex-compat HSregex-posix
>>         HSregex-base HSparsec HSbase
>>         HSbase_cbits HSrts m gmp dl rt
>>
>>
>>
>>> There is a project for this year's Google Summer of Code to use dynamic
>>> libraries on Linux. Perhaps this would make the situation better for you
>>> since dynamic libs record their own dependencies much better. Ideally
>>> you would only have to link to your own Haskell package built as a .so
>>> and that would pull in the dependencies on HSbase.so, HSrts.so and the
>>> other system libs.
>>>
>>> Duncan
>>>
>> Then it would be very similar to the windows build steps and probably 
>> a bit
>> easier since one wouldn't have
>> to mess with dlltools and converting libraries to ms vc formats etc.  
>> Really
>> all that's needed though is a tool that can automagically wrap a 
>> homegrown
>> static or even dynamic library that contains the needed components of the
>> GHC run time library along with the additional user code.  I know all the
>> object files are available as are of course the libraries themselves, so
>> such a script is not impossible.  It seems that ghc itself is doing some
>> kind of dependency analysis to determine the final call to gcc.
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>>
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
> 
>