I think it would be a usefull addition to the haskell windows tool
chain, and help facilitate the creation of bindings to libraries on
windows where no appropriate import library exists.
I am sure if you put it "out there" in whatever form, someone will find
a use for it and perhaps build u
Hi Erik
I'm neither expecting nor obliging Unix users to do anything...
pexports (the C tool) extracts function names from dlls. In one of the
messages on the PortAudio thread [1], John Lask explained how to get
from a standard Windows .dll to an .a file suitable for GHC (which is
bundled with a
Stephen Tetley wrote:
> If there are compelling uses that aren't covered by pexports and would
> ease Haskell C binding problems on Windows, I don't mind polishing up
> my tool, but otherwise I've exhausted my natural interest.
I think the main problem you'll face is that pexports is a windows
on
Hi All,
Would a pure Haskell version of pexports be useful to the Haskell community?
For a Sunday afternoon hack that turned out to take a bit more effort
(its now Wednesday), I thought I'd code up a tool that extracts
function symbols from .dll's (also when I first looked at the C
pexports it se
john lask wrote:
I think there are some misapprehensions here:-
Many haskell packages binding to c libraries will compile with ghc
without problems on windows - without cygwin, without mingw/msys system.
OK, well I haven't tried building every C binding on all of Hackage,
just a few of them.
I think there are some misapprehensions here:-
many haskell packages binding to c libraries will compile with ghc
without problems on windows - without cygwin, without mingw/msys system.
Some such packages build "out of the box" on windows, like the zlib
package which contains the c source for