[Haskell-cafe] Re: binding to C libraries on Windoww

John Lato jwlato at gmail.com
Mon Dec 7 07:41:28 EST 2009

To reply to an earlier point of Andrew's (I can't find the quote now,
sorry), one of the biggest difficulties developers face on Windows is
the lack of common install locations/practices.  Windows software is
usually distributed as a binary, which may or may not include header
files.  These files may be installed in any of numerous locations,
such as C:\Program Files\, the user's home directory, the system
directory, or directly off the drive root.  Defaults are not common
among different programs or even versions of programs, and install
locations are frequently changed by users anyway.  Libraries and
headers are usually not located on the PATH environment variable, and
there's no standard INCDIR or LIBDIR variable either.

While it is Cabal's job to find the location of necessary libraries,
header files, and tools, there simply is no feasible way to do so on
Windows without searching most of the hard drive.  Even then, there's
no guarantee the right version will be found (google "DLL Hell" for
examples of the chaos that ensues).  This is particularly true for
developers, who frequently have multiple versions of libraries
installed.  The only workable approach is to have users specify the
locations of these files, which unfortunately requires more
sophistication than can be expected of most Windows users (and even
some Windows developers).

On a related matter, many packagers resort to using configure-style
configuration setups to assist with binding to C libraries.  Cabal is
now sophisticated enough to handle many of these steps (although not
all), however packagers may not have had an opportunity to update
their build process to remove the dependency on "configure".  These
packages will continue to require cygwin or mingw for the "configure"

One last wrinkle: many distributors of C libraries do not have Windows
machines available to test, and (understandably) have little interest
in supporting a platform they don't have and aren't familiar with.  As
a result, many C libraries are not well supported on Windows and
require somebody familiar with gnu build tools (i.e. gcc, make, and
autoconf) to be usable on Windows *at all*.  This means that, as a
Haskell developer wanting to use these libs, you need to use gnu build
tools because you're not just binding to the library, you're
maintaining a Windows port of it.

C and unix are pretty much designed to work together, and have been
for decades, so I think it's reasonable to expect that Windows is the
side that needs to adapt to support their model.  MS hasn't done so,
which means that C developers would need to unacceptably compromise
unix support in their packages in order to better support Windows.
Cross-platform support precludes windows-native solutions, so you're
left making the best of it with Linux tools (mingw and cygwin) on


More information about the Haskell-Cafe mailing list