[Haskell-cafe] Export Haskell Libraries
mattcbro at earthlink.net
Fri Apr 13 02:38:36 EDT 2007
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
I'm afraid that the link stages for the software I have integrate to may be
and I thought that maybe this would not be the best approach if there were
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
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,
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
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.
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
View this message in context: http://www.nabble.com/Export-Haskell-Libraries-tf3569747.html#a9973642
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
More information about the Haskell-Cafe