cabal ignores ld-options?

Frederik Eaton

21 Apr 2007 21 Apr '07

11:11 p.m.

Hello, I am trying to get cabal to link an object file with a library. I tried naming it in an ld-options: line, but it didn't show up in the arguments to 'ld'. Is this the correct behaviour? I am using ghc-6.6.20070420. Thanks, Frederik

Show replies by date

Duncan Coutts

22 Apr 22 Apr

7:31 a.m.

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.

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

...

I tried naming it in an ld-options: line, but it didn't show up in the arguments to 'ld'. Is this the correct behaviour?

For a bug report like this it's much more helpful if you give more detail on exactly what you did, exactly what happened and what you were expecting. In this case for example you could include the output of runghc Setup.hs build -v so you and we could see exactly how cabal is calling ghc/ld/whatever. The ld-options are passed to ghc when it links an executable and they also get included in library package registration information. Duncan

Frederik Eaton

10:51 a.m.

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.

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 tried naming it in an ld-options: line, but it didn't show up in the arguments to 'ld'. Is this the correct behaviour?

For a bug report like this it's much more helpful if you give more detail on exactly what you did, exactly what happened and what you were expecting. In this case for example you could include the output of runghc Setup.hs build -v so you and we could see exactly how cabal is calling ghc/ld/whatever.

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]$ Thanks, Frederik -- http://ofb.net/~frederik/

Duncan Coutts

23 Apr 23 Apr

3:37 a.m.

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

Frederik Eaton

5:20 a.m.

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

Duncan Coutts

7:26 a.m.

On Mon, 2007-04-23 at 06:20 +0100, Frederik Eaton wrote:

...

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

Sure, an explicit statement of coverage, what it does and doesn't handle yet etc would be a very good thing.

...

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

Ah yes I see, but that still would not do what you want. The ar call is to make the ordinary static lib. The ld call is to make the GHCi .o equivalent. So if you added a .o file to the ld arguments there but not for ar then your thing only work with GHCi and not in the normal static linking case.

...

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.

Right. As I said we do have a mechanism in Cabal to compile C files and include them in a package. I was suggesting and asking for feedback on a similar mechanism to allow arbitrary .o files to be included too.

...

If the Cabal documentation were correct, then I think ld-options would be what I want.

As I say, it would not be what you want. You need to be able to specify a bunch of other object files to link in, like we have the c-sources: field. You'd want other-object-files: or something along those lines.

...

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

I think so but I'm not 100% sure.

...

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.

It doesn't scale to have cabal try and build sources from lots of other languages. C is a special case. If you're doing a multi-language project you need something else at the top level of your build system. You can use cabal to build the Haskell part and whatever else to build the other language stuff. Each can produce their .a / .so files which you install together or link together. Duncan

Malcolm Wallace

12:57 p.m.

Duncan Coutts wrote:

...

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.

*cough* nhc98 Not that Cabal actually supports nhc98 yet... Regards, Malcolm

Duncan Coutts

11:02 p.m.

On Mon, 2007-04-23 at 13:57 +0100, Malcolm Wallace wrote:

...

Duncan Coutts wrote:

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

*cough* nhc98

Oh ok :-). So some (at least nhc, ghc and jhc) support linking to arbitrary .o files. So is this a feature that should be exposed through cabal do you think? I'm pretty sure there are implementations which do not support this: yhc and hugs, though I don't really know how hugs or yhc's ffi support works so I might be wrong about that.

...

Not that Cabal actually supports nhc98 yet...

We'll gladly accept patches :-) Duncan

Stefan O'Rear

11:09 p.m.

On Tue, Apr 24, 2007 at 09:02:39AM +1000, Duncan Coutts wrote:

...

On Mon, 2007-04-23 at 13:57 +0100, Malcolm Wallace wrote:

...
Duncan Coutts wrote:

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

*cough* nhc98

Oh ok :-).

So some (at least nhc, ghc and jhc) support linking to arbitrary .o files. So is this a feature that should be exposed through cabal do you think? I'm pretty sure there are implementations which do not support this: yhc and hugs, though I don't really know how hugs or yhc's ffi support works so I might be wrong about that.

IIRC yhc uses the Posix dynamic linker/loader infrastructure, so it needs .so not .o.

...

...
Not that Cabal actually supports nhc98 yet...

We'll gladly accept patches :-)

stefan@stefans:~/vty$ ./Setup.lhs configure --help | grep nhc -n --nhc compile with NHC stefan@stefans:~/vty$ If cabal doesn't support NHC, why does it advertise support? Stefan

Duncan Coutts

11:20 p.m.

On Mon, 2007-04-23 at 16:09 -0700, Stefan O'Rear wrote:

...

IIRC yhc uses the Posix dynamic linker/loader infrastructure, so it needs .so not .o.

Right, that's fair enough.

...

...
...
Not that Cabal actually supports nhc98 yet...

We'll gladly accept patches :-)

stefan@stefans:~/vty$ ./Setup.lhs configure --help | grep nhc -n --nhc compile with NHC stefan@stefans:~/vty$

If cabal doesn't support NHC, why does it advertise support?

Don't ask me I'm just a cabal patch monkey :-). Perhaps I shouldn't admit it but I've never personally tried cabal with nhc. I should probably fix the nhc gentoo ebuild and try it some time. Duncan

Malcolm Wallace

24 Apr 24 Apr

10:39 a.m.

...

...
So some (at least nhc, ghc and jhc) support linking to arbitrary .o files. So is this a feature that should be exposed through cabal do you think?

Ultimately, if a Haskell implementation supports the FFI, it must be able to link arbitrary object files. Although as Stefan points out, the actual format might vary between .a, .o, .so, and .dll. The formal FFI specification allows for individual foreign imports to specify the name of the appropriate object file in a platform-independent manner. So yes, I imagine Cabal should support it somehow.

...

...
...
Not that Cabal actually supports nhc98 yet... We'll gladly accept patches :-)

Patches would require someone who understands both the internals of Cabal, and the structural layout of nhc98. Guess which is the more complex. :-)

...

-n --nhc compile with NHC If cabal doesn't support NHC, why does it advertise support?

$ grep NHC Distribution/Simple/Install.hs NHC -> die ("installing with nhc98 is not yet implemented") Regards, Malcolm

6649

Age (days ago)

6652

Last active (days ago)

List overview

Download

10 comments

4 participants

participants (4)

Duncan Coutts
Frederik Eaton
Malcolm Wallace
Stefan O'Rear

cabal ignores ld-options?

tags

participants (4)