RE: GHC 6.4 release candidates available (breakage on suse 9.2 x86or x86-64)
On 22 February 2005 20:05, Brian Strand wrote:
I'm having some serious "issues" getting GHC to run on Suse 9.2/x86 (or x86-64 for that matter, although I didn't really expect that to work without some pain and suffering). I've had no luck with 6.2.2, or any 6.4 release candidate. Here is a typical example: after doing a "./configure; make in-place", I get the following:
/home/bstrand/haskell/ghc-6.4.20050221/lib/i386-unknown-linux/ghc-6.4.20 050221:
error while loading shared libraries: libreadline.so.4: cannot open shared object file: No such file or directory
Fair enough; "rpm -q readline" gives me readline-5.0-1.2. So off to the sources I go:
cd ~/src/ghc-6.4.20050221 ./configure ... configure: error: GHC is required unless bootstrapping from .hc files.
After reading through most of the GHC building guide (paying particular attention to section 10), I try:
./configure --enable-hc-boot
You actually need the .hc source files too, which don't come with the source distribution because they have to be built for each target platform. That section of the Building Guide wasn't really clear enough on this issue, so sorry if that meant you wasted some time. We've since updated the instructions in the Building Guide. For compiling GHC on a platform for which you don't already have a GHC binary, the Approved Method is to go through the unregisterised bootstrap instructions in section 10.2. It's possible to do a registerised bootstrap, which would be shorter, but we haven't tested and documented the procedure. Cheers, Simon
Simon Marlow wrote:
[ snipped ] You actually need the .hc source files too, which don't come with the
On 22 February 2005 20:05, Brian Strand wrote: source distribution because they have to be built for each target platform.
That section of the Building Guide wasn't really clear enough on this issue, so sorry if that meant you wasted some time. We've since updated the instructions in the Building Guide.
For compiling GHC on a platform for which you don't already have a GHC binary, the Approved Method is to go through the unregisterised bootstrap instructions in section 10.2. It's possible to do a registerised bootstrap, which would be shorter, but we haven't tested and documented the procedure.
Cheers, Simon
Thanks, good to know; I'll read through 10.2 more carefully. I didn't think I'd need to cross-compile x86-linux to x86-linux. Would it be unreasonable to include the unregisterised .hc files with a source distribution (or .hc files for "popular" platforms), so that a Haskell novice such as myself could do a "./configure && make && make install"? If configure detected no ghc, perhaps it could do the bootstrap automagically. Or is ghc/Haskell established enough that the existence of some Haskell compiler is taken for granted nowadays? Thanks again to everyone on the list for the helpful advice! Brian
Thanks, good to know; I'll read through 10.2 more carefully. I didn't think I'd need to cross-compile x86-linux to x86-linux.
You don't need to - the recommended way is to download a binary version. If you don't like using binary distributions, then use it for bootstrapping only, i.e. use it to build a ghc of your choice and then delete it again. This is just like what you usually do when you install gcc on your box for the first time.
Would it be unreasonable to include the unregisterised .hc files with a source distribution (or .hc files for "popular" platforms), so that a Haskell novice such as myself could do a "./configure && make && make install"? If configure detected no ghc, perhaps it could do the bootstrap automagically.
Well, the contents of the .hc files heavily depend on the results of ./configure - so unregistered .hc files still have to be tailor-made for the target platform. As far as registerised .hc files for popular platforms go, I fail to see the point. In what way is bootstrapping from platform-specific .hc files superior to installing a binary (apart from the fact that it takes longer and looks cooler)? It would be like shipping GCC as a bunch of x86 .s files. Cheers, Wolfgang
Wolfgang Thaller wrote:
Thanks, good to know; I'll read through 10.2 more carefully. I didn't think I'd need to cross-compile x86-linux to x86-linux.
You don't need to - the recommended way is to download a binary version. If you don't like using binary distributions, then use it for bootstrapping only, i.e. use it to build a ghc of your choice and then delete it again. This is just like what you usually do when you install gcc on your box for the first time.
I originally tried the binary distribution but ran into library issues. That is of course the obvious path to try, and try it I did. Rather than going straight to installing deprecated libraries, I tried to provide some feedback on ghc (especially since 6.4 RCs are out).
Would it be unreasonable to include the unregisterised .hc files with a source distribution (or .hc files for "popular" platforms), so that a Haskell novice such as myself could do a "./configure && make && make install"? If configure detected no ghc, perhaps it could do the bootstrap automagically.
Well, the contents of the .hc files heavily depend on the results of ./configure - so unregistered .hc files still have to be tailor-made for the target platform. As far as registerised .hc files for popular platforms go, I fail to see the point. In what way is bootstrapping from platform-specific .hc files superior to installing a binary (apart from the fact that it takes longer and looks cooler)? It would be like shipping GCC as a bunch of x86 .s files.
Cheers,
Wolfgang
I have no concern whatsoever with the appearance of "coolness" (or lack thereof). As stated above, I have no problem with installing a binary, but that option didn't work out at first, so, ghc being free software, I tried to compile it for my platform. When that failed, I decided to report back on my difficulties, hopefully helping anyone who runs into (and googles for) the same problem. (In fact at the moment I am doing exactly as you suggested, making a "clean" build of ghc via the binaries, so as not to clutter up our many Oracle boxen with (otherwise useless) backwards-compatibility readline libraries.) Regarding gcc, gcc binaries ship with or are available for every commonly used platform (and most uncommonly used platforms too); ghc is not (yet) in this position. I was fully aware of the parallel between distributing .s files with gcc and .hc files with ghc when I made this suggestion. Not being intimately familiar with ghc internals, I don't know how much work this is, and whether the implementation cost exceeds the benefit (easier installation for Haskell novices like me).
Brian Strand wrote:
I originally tried the binary distribution but ran into library issues. That is of course the obvious path to try, and try it I did. Rather than going straight to installing deprecated libraries, I tried to provide some feedback on ghc (especially since 6.4 RCs are out).
Well, it seems like I should have read your previous posts more attentively before mentioning the recommended way of doing things again - sorry.
Not being intimately familiar with ghc internals, I don't know how much work this is, and whether the implementation cost exceeds the benefit (easier installation for Haskell novices like me).
My guess is that for GHC, it won't work; the .hc files are really too low-level. Just about the only thing that's not already decided in the .hc files (that I can think of now) is the actual names of the libraries that the app links to. We'd need to supply .hc files for nearly as many platforms as we need binaries for. So maybe x86-Linux needs a ghc binary with as few library dependencies as possible, to facilitate bootstrapping on different Linux distros? Cheers, Wolfgang
Wolfgang Thaller wrote:
Brian Strand wrote:
Not being intimately familiar with ghc internals, I don't know how much work this is, and whether the implementation cost exceeds the benefit (easier installation for Haskell novices like me).
My guess is that for GHC, it won't work; the .hc files are really too low-level. Just about the only thing that's not already decided in the .hc files (that I can think of now) is the actual names of the libraries that the app links to. We'd need to supply .hc files for nearly as many platforms as we need binaries for. So maybe x86-Linux needs a ghc binary with as few library dependencies as possible, to facilitate bootstrapping on different Linux distros?
That seems like a very good idea to me; for bootstrapping, one doesn't need ghci, readline, ncurses, etc. From "ldd ghc-6.4.20050221", it looks like the only really essential non-libc library is libgmp (which I'm guessing is used for Integer operations at least, and these are hard to do without...).
Just a quick comment on a couple of things Brian Strand writes:
Or is ghc/Haskell established enough that the existence of some Haskell compiler is taken for granted nowadays?
Ghc is not written in pure Haskell - it is written in Ghc Haskell, i.e. it uses many extensions and internal libraries not available in all other Haskell implementations. Thus, you really need ghc to bootstrap ghc.
Would it be unreasonable to include the unregisterised .hc files with a source distribution (or .hc files for "popular" platforms), so that a Haskell novice such as myself could do a "./configure && make && make install"? If configure detected no ghc, perhaps it could do the bootstrap automagically.
This is what nhc98 does - supplies platform independent .hc files for bootstrapping via gcc if no existing Haskell compiler is installed. However, nhc98 uses a bytecode VM, so it produces code that is 3x - 15x slower than ghc, (currently) lacks many of the lower-level libraries, and implements very few language extensions. Thus it has a smaller user base, and smaller maintainer base too (therefore not much ongoing development). Ideally, if ghc were implemented in something closer to Haskell'98, it would be possible to double-bootstrap up from gcc -> nhc98 -> ghc unregisterised -> ghc registerised, on almost any new platform. But the amount of work required to 98-ify ghc is considerable (there are 148 kLoC to check), and it is hard to say whether it would be worthwhile. Maybe someone fancies tackling it as a medium-size project? Regards, Malcolm
On Thu, Feb 24, 2005 at 11:12:06AM +0000, Malcolm Wallace wrote:
Ideally, if ghc were implemented in something closer to Haskell'98, it would be possible to double-bootstrap up from gcc -> nhc98 -> ghc unregisterised -> ghc registerised, on almost any new platform. But the amount of work required to 98-ify ghc is considerable (there are 148 kLoC to check), and it is hard to say whether it would be worthwhile. Maybe someone fancies tackling it as a medium-size project?
It might be easier to extend nhc98 with some of the extensions needed by ghc. Actually, how difficult would it be to translate ghc core to something nhc could use? Then we could use the ghc front end with nhcs back end. I am not sure what nhcs intermediate language looks like, but ghc core is similar enough to desugared haskell that it seems like it should be possible. The main issue I can think of is a mismatch in the primitive operators, so one would probably have to use ghcs front end with nhcs prelude/other libraries. John -- John Meacham - ⑆repetae.net⑆john⑈
participants (5)
-
Brian Strand -
John Meacham -
Malcolm Wallace -
Simon Marlow -
Wolfgang Thaller