On Mon, Apr 23, 2007 at 01:37:14PM +1000, Duncan Coutts wrote:
On Sun, 2007-04-22 at 11:51 +0100, Frederik Eaton wrote:
On Sun, Apr 22, 2007 at 05:31:31PM +1000, Duncan Coutts wrote:
On Sun, 2007-04-22 at 00:11 +0100, Frederik Eaton wrote:
Hello,
I am trying to get cabal to link an object file with a library.
Frederik, in case it's not clear, the reason you're running into problems is because you're doing things people haven't done much before with cabal, that is try and use it as part of a larger multi-language project. I'm not at all saying that's a bad thing, it's just that's why you're noticing these missing features.
OK, well perhaps a warning in the Cabal documentation is in order: "Don't use this system if you need flexibility." People have been telling me to use Cabal and that is why I used it. I thought it was a bad idea from the beginning, but I took their advice.
Do you mean you want to link to an existing C library? You don't need ld-options for that of course, just extra-libraries (and maybe extra-lib-dirs).
No, I have an object file which I have compiled with g++, and a Haskell library which uses symbols from it. I usually just put it on the ghc command line and that seems to work, but don't know what the Cabal equivalent of this technique is.
I see. It might be easier to make this into a library, ie an archive .a file. Cabal has no particular mechanism for linking in arbitrary .o files but it does have a mechanism for linking to libraries.
OK, thanks.
The ld-options are passed to ghc when it links an executable and they also get included in library package registration information.
OK, I've attached my cabal file and a transcript of the verbose output.
$ grep string vectro.cabal ld-options: this string never appears anywhere as far as i can tell $ grep string cabal.out [1]$
Right, since you're making a library ld is never called (it's ar that is used to make an .a archive file).
That is not true, both ld and ar are called. See the file named cabal.out which I attached to my previous message. When ld is called, then object files for compiled C files are included on the command line (gslaux.o), so I would expect object files for compiled C++ files to belong here as well. If the Cabal documentation were correct, then I think ld-options would be what I want.
You should find that the ld-options have been included in the package registration file, ie if you register and say: ghc-pkg describe vectro, then you'll see that your ld-options will get used when linking all programs that use your library.
That is the case. Perhaps two different ld-options fields are needed?
For your example this is almost certainly not what you want.
So I think the right thing to do is to make an .a archive from your extra .o files and list that in the extra-libraries: field. You'd need to arrange for that archive to be installed too. I guess you must have some outer build system since you're invoking g++ anyway. I'm not sure how or if you could get cabal to install an extra archive into the right place. I'm not sure how they do it for the base lib which has this extra _sbits.a archive. That might be worth looking at.
Perhaps there should be a mechanism to include arbitrary extra .o files into the archive that cabal produces, but remember that this would be totally ghc-specific. No other Haskell implementations use archives or can necessarily link arbitrary .o files.
I see, so FFI in other implementations relies on dynamic or static libraries? Perhaps I should avoid using Cabal, since it has caused so much inefficiency. I will go through cabal.out and put those commands in a makefile. Frederik
On the other hand we do already have a mechanism to compile and include ordinary .c files in a package.
Any cabal devs/users have any opinions on this?
Duncan