Hello, 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 ftp://ftp.cwru.edu/pub/bash/readline-5.2.tar.gz. 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 ftp://ftp.cwru.edu/pub/bash/readline-5.2.tar.gz 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 http://hackage.haskell.org/trac/ghc/ticket/1395 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. Finally: 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 Thorkil 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/build.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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe