cabal ignores ld-options?

[Frederik Eaton]

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