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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- 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.