cabal ignores ld-options?

[Duncan Coutts]

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.

> > 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.

> > 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). 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.

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.

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