Dynamic Libraries on MacOS X

[Wolfgang Thaller]

Hi Everyone,

I've run into some problems/"design issues" for GHC/MacOSX, and I'd like to hear other people's opinions on the subject. Sorry for the long post.

Programs compiled by GHC for MacOS X currently depend on two libraries that are not included with MacOS X:

*) dlcompat - a compatibility layer implementing the dlopen API,
         which is not normally available on MacOS X (BSD-style license)
*) libgmp - support for the Integer type, under LGPL

The Problem:
*) Most Mac users don't know how to install unix-style dynamic libraries. They shouldn't be expected to know. The MacOS Finder (Apple's File Browser) hides the entire /usr directory hierarchy be default. Requiring everyone who uses a program written in Haskell to install a dylib is not an option on MacOS.

*) The LGPL imposes serious restrictions on all programs statically linked with libgmp, so static linking is not an option, either.

*) Dynamic libraries anywhere on the system take precedence over static libraries, so if GHC included static versions of the libraries, developers could still accidentally create programs that depend on the dylibs.

Possible Solution:
Frameworks. A "Framework" on MacOS X is a directory that contains a dynamic library plus associated resources and header files. There is an extra compiler/linker option for linking to a framework. The big advantage is that the place they are supposed to be installed in is accessible from the user interface.
I've created a framework called "HaskellSupport.framework", and I've made ghc link to that.

Disadvantage:
Problems with GHCi (yes, I've almost got it to work!) - "-framework HaskellSupport" is in the extra_ld_opts field of the RTS package, so GHCi doesn't know that it has to load the libraries.

Related Problem:
Sooner or later, GHC for MacOS X should support Apple's Frameworks anyway, as almost all functionality beyond the standard C library is packaged in frameworks. I don't know yet how much work that would be for me, and I fear that the ghc gurus would dislike too much platform-specific code for Apple's non-standard features... Here's what I'd like to do:
*) add two command line options that get passed on to the linker (-framework for linking with a framework and -F for specifying framework search paths)
*) add corresponding entries to package.conf
*) add code for GHCi to load frameworks.

I'm looking forward to everyone's opinions.

Cheers,
Wolfgang