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
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
