[Haskell-cafe] Re: Export Haskell Libraries

Simon Marlow simonmarhaskell at gmail.com
Fri Apr 13 08:49:17 EDT 2007


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
> 
> 



More information about the Haskell-Cafe mailing list