Cabal should be able to produce foreign libs (shared or static)

[bos]

(Imported from Trac #148, reported by eivuokko on 2007-08-23)

GHC supports linking final executable into a DLL instead of normal executable. Cabal should support this use, and also support specifying DEF file for exports and building an import library.

[bos]

(Imported comment by @dcoutts on 2007-08-23)

http://www.haskell.org/ghc/docs/latest/html/users_guide/win32-dlls.html#win32-dlls-create

[bos]

(Imported comment by @dcoutts on 2007-08-23)

Needs someone to take ownership of this.

[bos]

(Imported comment by @dcoutts on 2008-01-24)

What is a dll really? It's not an executable and it is not a library, at least not the thing that cabal calls a library.

It's actually a hybrid concept. It's statically linked (at least the way we do it now), linking in the rts and all the dependent haskell packages. So in that respect it's just like an executable. Obviously it exports more than just main, it exports all the ffi exported C functions (right?).

How are the exports specified? Are they just the ffi exports? We don't really need a manually written .def file do we?

So is this concept something we can and want to support in Cabal? Does it have any cross-platform meaning at all?

If it's a different class of target from executables and libs then I think we should support it as such and not try and cram it into one of the existing templates.

Something like:

name: foo
version: 1.0
foreign_dynamic_library
  build-depends: bar
  other-modules: Foo

Though obviously with a more sensible name for the thing than foreign_dynamic_library.

[bos]

(Imported comment by @dcoutts on 2008-03-06)

More people are trying to do this kind of thing, see:
http://ha4.fajno.net/2009/03/pandoc-can-we-use-it-ouside-of-haskell.html

There are also plenty of people in commercial settings doing this on Windows and who could do with more help from Cabal.

This ticket mentions Windows and DLLs but we have the same issue with Unix systems and generating shared or static libs for consumption by foreign code. Whatever solution we come up with should be as cross-platform as possible.

One question, is the choice of static lib or dynamic lib part of the package description or part of the way we choose to build it? Should we be able to build both from the same description? When you're building it, should you have to specify if you want to make a static lib or shared lib?

For Haskell libs we have to say at configure time if we want shared or static. For this case perhaps it's more part of the package description than a configuration option.

For Windows DLLs I hope there will be no need to specify .def files. We should be able to get the exact export list from the list of FFI ccall/stdcall exports.

Note this issue is independent of whether ghc supports shared libs for the RTS and Haskell packages on a particular platform. If it doesn't we just generate massive libs that link in everything. If it does we can make small libs that dynamically link to the RTS and Haskell packages.

[23Skidoo]

See #2540.

[phadej]

is this done?

[23Skidoo]

Yep, I think this ticket can be closed given that we now have foreign-library.