readline problems building GHC on Mac OS X (was: Re: [Haskell-cafe]
Re: ANNOUNCE: GHC version 6.8.2)
Thorkil Naur
naur at post11.tele.dk
Fri Dec 21 18:40:24 EST 2007
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 at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
More information about the Haskell-Cafe
mailing list