Dougal Stanton wrote,

I'd guess there should be a way to get the libreadline4 installed from your package manager. Something like "sudo yum install libreadline4" maybe? I don't use FC myself, so can't help further.

It's even easier than that ... on Fedora Core 6 all he had to do was, yum install ghc Cheers, Miles

On 4/27/07, C.M.Brown wrote:

Wow! Such a bitter response! All you need to do is install readline, found here:

http://tiswww.case.edu/php/chet/readline/rltop.html

I think it's unfair to blame GHC for not having readline; the website does

indeed tell you about readline:

http://www.haskell.org/ghc/download_ghc_661.html

Thanks to all for the helpful responses. I was just operating in "automated mode" so I didn't read all the text in the download page, just clicked to start the download and moved on... But just think about it... is it easier to DOCUMENT the problem or just include a workaround in the make install code? IF {library not available} then echo "you need to get asdfzxcv lib. before the compiler will work. please use yum or apt-get" Is that too much to ask for?. The fingers of both hands are not enough to count situations like this where developers spend more time documenting the problem rather than fixing it with some user-friendlyness in the install script. Again, thanks for the help. FC

On Fri, 27 Apr 2007 07:00:26 -0300 "Fernando Cassia" wrote:

But just think about it... is it easier to DOCUMENT the problem or just include a workaround in the make install code?

It's easier to document the problem.

IF {library not available} then echo "you need to get asdfzxcv lib. before the compiler will work. please use yum or apt-get"

Virtually no other open source project does this, in my experience. It's better just to use yum in the first place, and only if that doesn't work, try the tarballs. -- Robin

Michael T. Richter wrote:

On Fri, 2007-27-04 at 13:09 +0100, Robin Green wrote:

...

...

But just think about it... is it easier to DOCUMENT the problem or just include a workaround in the make install code?

...

It's easier to document the problem.

For the individual developer it is easier to document the problem. For the development community as a whole it is easier if individual developers fix problems or at least make them more easily spotted than obscure notes in gigantic README files.

For the individual developer it takes, hypothetically, two minutes to add a note to the effect that an out-of-date version of libreadline is required while it may take ten minutes to add a check to the configure script (and test it!) and even a day to fix the problem to work with the current version of libreadline. So yes, it is easier to document. By far.

But now broaden the scope to the community. The compiler is downloaded. The process of building it begins. (It does take a long time to build GHC...) The user waits that long time and ... the build fails. Now s/he has to search through output whose error messages are not exactly the most friendly in the world. Typically, for example, you're about five levels deep into make and the error message that actually tells you what's wrong is in backscroll. So you find that message and slap your forehead. Doh! You download and install your old version of libreadline and try again. Time wasted? Ten minutes at least. More likely half an hour. Lather. Rinse. Repeat. (There are probably other dependencies to outdated packages, after all.)

OK, let's go the RTFM route. Each and every developer reads each and every README file in each and every project combing it for references to bizarre dependencies. Let's be hyper-generous and say that each developer only spends one minute on the README file; that the README files in question are a paragon of informational organisation (instead of the more usual data dump in no particular order). Let's further suggest that it takes only five minutes to get all the unexpected dependencies worked out, downloaded and compiled/installed. Total time to make up the fix? Six minutes.

That one minute to find the information in the README file is far shorter than the time it would take to add the equivalent logic to the configure script. So if you have one to nine end-users, the net time wasted to document instead of modifying the configure script is less. But I think that GHC has quite a few more than nine end-users. The aggregate time wasted in the community (without even factoring in the time required to compile/install the desired version of libreadline) suddenly becomes much higher than the time saved by not writing that configure script modification. Indeed I suspect that the aggregate time wasted would be sufficient to justify the modification of the code to support the latest version of libreadline in the first place once you factor in the time wasted compiling/installing the correct libreadline version.

Now what relevance does any of this have to the individual developer? Why would s/he care about the end-user experience? Well, let us not forget that said individual developer is part of that overall community. That said individual developer faces exactly the same wastes of time poring over README files (or, more likely, bizarre build errors) to figure out how to get the tools they use to compile. That said developer, too, would be more productive individually, not to mention the community as a whole, if the majority of the development community's members were to fix problems rather than documenting them.

All these would be a very good points except they do not match the actual situation at all. 1) The compiler was not built from source. 2) The compiler built successfully. 3) [root@localhost ghc-6.6.1]# ghc /usr/local/lib/ghc-6.6.1/ghc-6.6.1: error while loading shared libraries: libreadline.so.4: cannot open shared object file: No such file or directory Finding one line in one line of output... quite a bit of rooting around. 4) The fix to the "bug" is simply download and install the libreadline4 shared object. No recompilation or reinstallation necessary. 5) The "gigantic README" with it's "obscure note" is here http://www.haskell.org/ghc/download_ghc_661.html a few lines away from the download link. You can probably read it in the time it takes you to find and click the download link. Much quicker than waiting for a configure script to detect the problem.

On 4/29/07, David House wrote:

The fact remains that there is a bug in the build process (configure doesn't check for all the dependencies), and that users have fallen afoul of the bug, so it should be fixed, no matter how well the workaround is documented.

-- -David House, dmhouse@gmail.com

That was my point. Applause. ;) FC -- Dream of the Daily Mail It is the Holy Grail And then the BBC Your life would be complete -Manic Street Preachers, "Royal Correspondent"

ls-haskell-developer-2006@m-e-leypold.de wrote:

...

5) The "gigantic README" with it's "obscure note" is here http://www.haskell.org/ghc/download_ghc_661.html a few lines away from the download link. You can probably read it in the time it takes you to find and click the download link. Much quicker than waiting for a configure script to detect the problem.

Also, just in case one doesn't know where to look, doing a web search for 'ghc "libreadline.so.4"' gives enough hits to solve the problem. The OP insisisted on compiling from the source (which is OK),

Just wanted to clear up a misconception I've seen several times in this thread: the OP was *not* building from source, he was installing from a binary distribution tarball. The confusion no doubt arises because our binary tarball has a configure script and a Makefile. The real build system *does* check for readline, as it should. The tarball is built on an old RedHat 9 system with readline 4 on it. The main reasons we supply the binary tarball (as opposed to distro packages) are so that you can install GHC in your home directory, or install multiple versions of GHC, or try out new releases without installing them system-wide. I'm going to upgrade the machine that builds these distributions at some point, but it's in the data center and I find it a bit cold and windy in there :-) Typically the best way to get GHC on Linux is directly from your distro. The download page for 6.6.1 is currently not particularly helpful, we will be improving it in due course. Cheers, Simon

brad clawsie writes:

...

4) The fix to the "bug" is simply download and install the libreadline4 shared object. No recompilation or reinstallation necessary.

i'm not sure if this has been addressed - but is there a specific reason an older version of the readline library is in use? v5 appears to be stable and has been in use for some time now.

Actually some sources recommend to just symlink libreadline.so.4 to libreadline.so.5. I haven't tried, but since version 5 is supposed to be upwards compatible to version 4 it's reasonable to expect that it works (to a certain extend). To me (as an outsider) the whole thing certainly looks like a quirk/buglet in the ghc build process (why not just link to the available readline?), but IMO that is no reason for a "ghc is not ripe for prime time" outcry. Ghc is for programmers and there is a certain extend of ability to help yourself I'd be expecting from programmers. If one doesn't have it, he/she should just use the packages of his/her distro or another distro. Regards -- Markus

brad clawsie wrote:

installing a modern linux on this box is a thirty minute exercise.

Ah - a volunteer! :-)

On Mon, 2007-30-04 at 18:35 -0700, brad clawsie wrote:

On Mon, Apr 30, 2007 at 09:53:06PM +0100, Andrew Coppin wrote:

...

brad clawsie wrote:

...

installing a modern linux on this box is a thirty minute exercise.

Ah - a volunteer! :-)

absolutely! for the low cost of one round-trip business-class seat from san jose to wherever this box is, and i will happily insert a recent ubuntu cd and click the install icon.

You beat me to it. -- Michael T. Richter (GoogleTalk: ttmrichter@gmail.com) The most exciting phrase to hear in science - the one that heralds new discoveries - is not "Eureka!" but "That's funny..." (Isaac Asimov)

I think it's unfair to blame GHC for not having readline; the website does indeed tell you about readline:

http://www.haskell.org/ghc/download_ghc_661.html

Check out the paragraph under "Linux (x86)".

shouldn't library dependency checking be done in the ./configure script?

On Sat, Apr 28, 2007 at 12:11:30PM -0300, Fernando Cassia wrote:

On 4/27/07, Joe Re wrote:

...

Perhaps you were installing by tarball because you thought Fedora doesn't have a recent version of ghc in their repositories?

Exactly. I saw the latest version was very recent, didn't think any FC6 repos woudl have it. As a matter of fact I wasn't even aware that FC6 repos had ANY haskell compiler in there.

Note that the Haskell standard hasn't been updated in almost ten years. The differences between GHC 6.6.1 and 6.2.2 (or whatever FC6 has) are relatively minor and almost only affect programs that are unportable to begin with.

...

Minor side note: ghc is just one of many (albeit the dominant) compiler for Haskell. Surely you wouldn't discredit C++ as a language just because your borland compiler broke? :-)

Don't worry, I wasn't as mad as I sounded. But I'm latin so I wanted to do a big scene so everyone pays attention and fixes this, either in the documentation, in the web page (by making the notice coloured red and <blink>blinking</blink> (joke), or in the ./configure script, or somewhere else.

Thanks to everyone for their replies and respect. I could as well have earned a flame or two, but you were all very cool and polite, which speaks volumes about the quality of the community you guys have here.

It has been said many times and I will say it again - in the long run, the only good thing haskell has is a community of nice people. Everything else is cloned quickly. Stefan