[Haskell-cafe] Re: Export Haskell Libraries
jason.morton at gmail.com
Fri Apr 13 10:23:36 EDT 2007
While we're on the topic, does anyone know if there exists a similarly
simple solution like the (last) section "Using both Python & Haskell
with ctypes" at
that works on Linux to easily link Haskell libraries/functions into Python?
On 4/13/07, Simon Marlow <simonmarhaskell at gmail.com> 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...
> 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
More information about the Haskell-Cafe