readline problems building GHC on Mac OS X (was: Re: [Haskell-cafe] Re: ANNOUNCE: GHC version 6.8.2)

Thorkil Naur naur at
Fri Dec 21 18:40:24 EST 2007


Although I have been building various GHC versions on various PPC Mac OS X 
systems for a while now, I'm afraid that I don't really have a good answer 
for your questions. However, your questions provide an excellect opportunity 
to discuss this, so that is what I am going to do.

There are several questions here: (1) Which readline do we use? (2) Where do 
we store it? (3) What do we call it? (4) How do we make the Haskell readline 
library build process select the right one? And perhaps (5) How do we 
persuade the GHC build process to make the Haskell readline build that 
happens as part of building GHC select the right one?

One at a time:

1. Which readline do we use? GNU readline, of course. As opposed to the 
readline installed as /usr/include/readline/*.h 
and /usr/lib/libreadline.dylib on our PPC Mac OS X machines which are said to 
be (and can even be observed to be) symbolic links to something called 
libedit and which, to me, never has managed to provide something suitable for 
use by GHC. But what is GNU readline, then? I don't exactly know, but my best 
guess is something like I 
never tried to install GNU readline directly from this file. On some 
occasions, I have installed readline from mac ports. Although I am fairly 
confident that what was installed was some version of the GNU readline, I am 
not sure. On other occasions, I have installed GNU readline from various 
sources related to GHC, some times known to me, at other times not.

2.Where do we store readline?  I don't know where a readline based on the GNU 
download would become 
installed (by default). The mac ports version installs by default 
at /opt/local/include/readline/*.h and /opt/local/lib/libreadline.*. Various 
readlines related to GHC have installed themselves (or were requested to 
become installed) as frameworks, this new and different Mac OS X mechanism 
for referring to a set of header files and corresponding library. So they have 
gone into /Library/Frameworks.

3. What do we call it? Here is where the interesting things start to happen: A 
central problem has been the ambiguity caused by Apple's decision to install 
symbolic links to the "edit" headers and "edit" library called "readline". 
And various mechanisms have been used to work around this problem: (a) If you 
have installed a mac ports readline at /opt/local/..., with GHC 6.6 at least, 
you were able to use the --with-readline-* options to direct GHC/the library 
build process to look in these directories first and thereby avoid the "edit" 
library; (b) At some point, a (possibly modified) version of the GNU readline 
library appeared, intended to be installed as a framework by the name of 
"GNUreadline" (as opposed to the bare "readline" name used earlier). This 
avoids the name clash caused by the Apple linking of "readline" to "edit". 
The problem that the Haskell readline library now needs to refer to a 
framework "GNUreadline" rather than ... (whatever it is that it refers to in 
a more Unix'y setting) is solvable. In addition, however, the readline 
library (or rather: The GNUreadline library derived from the readline 
library) refers to itself using the bare "readline" name, so that has to be 
changed also, leading to a need to maintain a complete and slightly modified 
version (GNUreadline) of the readline library.

It seems to me that this situation is less than ideal. I mean, in theory, 
somebody may come along at some point with some library calling itself 
GNUreadline and then we would have to adapt, doing the whole thing all over 
again. This manner of avoiding the name clash problem does not seem tenable 
in the long run.

Instead, what we should be able to do, is to specify, directly and to the 
point, that "readline", wherever we stored it, is what we want.

That possibility does not exist, unfortunately, so we will have to make the 
best use that we can of the existing mechanisms, as far as we can figure out 
what they are, to get the desired effect. And if it turns out that the 
existing mechanisms do not allow us to do what we want, we need to request 
extensions and modifications of the mechanisms, until they are able to 
support our requirements.

I am not quite sure that I am done with this subject, but let me go on with

4. How do we make the Haskell readline library build process select the right 
one? This is where I believe we can do something useful, making the Haskell 
readline library more capable in selecting its foundation readline library. I 
haven't worked out the details, some discussion is at and related tickets, but I am 
quite sure that methods can be found to select the desired readline library, 
without resorting to reissuing that library in a changed form and under a new 
name. And if this turns out to be absolutely impossible, I would much prefer 
pressing for the introduction of mechanisms that makes it possible to select 
the desired version of the library, removing this impossibility. Rather than 
issuing the library under a different name.


5. How do we persuade the GHC build process to make the Haskell readline build 
that happens as part of building GHC select the right one? Answer: I don't 
know. At some point, I did know, that was when the --with-readline-* options 
were introduced for the GHC ./configure. Nowadays, I am not sure.

Generally, I believe that it is fine for the GHC build process (whatever 
phase) to pass parameters to the build process of some library. But at the 
same time, the fact that such passing of parameters takes place must be very 
explicitly reported somewhere, in the output of the build process, probably.

Best regards

On Friday 21 December 2007 21:48, John Dorsey wrote:
> (Moving to the cafe)
> On a related topic, I've been trying to build 6.8.2 on Leopard lately.
> I've been running up against the infamous OS X readline issues.  I know
> some builders here have hacked past it, but I'm looking for a good
> workaround... ideally one that works without changes outside the GHC
> build area (besides installing a real readline).
> Here's what I noticed before I started drowning in the build platform.
> (I'm no gnu-configure expert nor GHC insider.)
> I can get gnu-readline installed from Macports, no problem.
> The top-level configure in GHC doesn't respond to my various attempts:
> o  using --with-readline-libraries and --with-readline-includes
> 	(Although it looks like the libraries/readline/configure script
> 	might recognize these, I can't get an option to pass through.)
> o  setting LDFLAGS and CPPFLAGS environment variables (with
> 	-L/opt/local/lib and -I/opt/local/include resp.) in my shell
> 	before running configure
> o  playing with the above settings and others in a mk/
> Until Apple fixes their broken-readline issue (maybe when the readline
> compatibility of libedit improves)... maybe the top-level configure can
> pass through flags or settings somehow?
> For those who've built with readline on OS X:  have you had to resort to
> blasting the existing readline library link, or is there a configuration
> option within the GHC tree that you've gotten to work?
> Should I be filing a trac bug instead of asking here?
> Thanks for any help.  There's no urgency for me; I'm just trying to get
> a working environment at home; I'd prefer to be able to bootstrap from
> the ground up; and I'd like to be able to contribute to testing/debugging
> on OSX.
> John
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at

More information about the Haskell-Cafe mailing list