Dear BDS hackers We'd like GHC to be buildable on BSD, but at the moment it isn't. We support GHC on Linux, Windows, Mac, but we really need help with BSD. Alas, we didn't get much response to Simon's message below. (One, I think -- thank you to that person! I think it was Kili, but I'm not sure.) So this message is to say: if you'd like GHC on BSD, please help! No help probably means no GHC. Time is short before GHC 6.10. "Help" means more than "can offer a remote login", but less than "solve it by yourself". We'll try hard to support you if you can invest a bit of time at your end. Many thanks Simon -----Original Message----- From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of Simon Marlow Sent: 02 September 2008 13:37 To: GHC Users Mailing List Cc: cvs-ghc@haskell.org Subject: *BSD GHC hackers needed... While perusing the tickets in the 6.10.1 milestone I spotted 3 that look to be FreeBSD-specific: 2476 internal error: awaitEvent: descriptor out of range 2502 segfault with GHC.Handle.fdToHandle' 2511 unix package doesnt load in ghci on freebsd/amd64 It's unlikely that we'll get to these in time for 6.10.1. Any FreeBSD hackers out there want to take a look? Help/advice is available as usual. There's also one NetBSD-specific ticket: 2351 NetBSD defines ELF_ST_TYPE (that one is easy), and one that I think applies to all the *BSDs: 2063 Breackage on OpenBSD due to mmap remap (actually the latter one is a top priority, because without it GHCi can't work, so we need it fixed for 6.10.1). Cheers, Simon _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Quoth Simon Peyton-Jones
Donn Cave wrote:
| ... and one that I think applies to all the *BSDs: | | 2063 Breackage on OpenBSD due to mmap remap | | (actually the latter one is a top priority, because without it GHCi can't | work, so we need it fixed for 6.10.1).
Is this a change from 6.8.3? NetBSD currently provides 6.8.3 as an optional package for NetBSD/i386 4.0, with ghci included and without any mmap patches as far as I know. It was also working for me on NetBSD/amd64 (which is the platform that would actually need MAP_32BIT?)
Yes, the code changed in the HEAD, and currently uses mremap(), which only exists on Linux. We need similar hacks that were done in 6.8.3 to get the BSDs to work, that is to allocate memory from some predefined address in the lower 2Gb of the address space. Cheers, Simon
On Tue, Sep 09, 2008 at 03:00:59PM +0100, Simon Marlow wrote:
Is this a change from 6.8.3? NetBSD currently provides 6.8.3 as an optional package for NetBSD/i386 4.0, with ghci included and without any mmap patches as far as I know. It was also working for me on NetBSD/amd64 (which is the platform that would actually need MAP_32BIT?)
Yes, the code changed in the HEAD, and currently uses mremap(), which only exists on Linux. We need similar hacks that were done in 6.8.3 to get the BSDs to work, that is to allocate memory from some predefined address in the lower 2Gb of the address space.
BTW: are there any big plans[tm] to replace all this OS specific hacks by something like dlopen(3) and friends for GHC 6.12? I really don't want to hack on Linker.c just to be see that hacking obsoleted in a year ;-) Ciao, Kili -- This email is ROT26 encrypted, by reading it you are in violation of the DMCA, and should turn yourself in to the authorities immediately. -- Chris Berry
Matthias Kilian wrote:
On Tue, Sep 09, 2008 at 03:00:59PM +0100, Simon Marlow wrote:
Is this a change from 6.8.3? NetBSD currently provides 6.8.3 as an optional package for NetBSD/i386 4.0, with ghci included and without any mmap patches as far as I know. It was also working for me on NetBSD/amd64 (which is the platform that would actually need MAP_32BIT?) Yes, the code changed in the HEAD, and currently uses mremap(), which only exists on Linux. We need similar hacks that were done in 6.8.3 to get the BSDs to work, that is to allocate memory from some predefined address in the lower 2Gb of the address space.
BTW: are there any big plans[tm] to replace all this OS specific hacks by something like dlopen(3) and friends for GHC 6.12? I really don't want to hack on Linker.c just to be see that hacking obsoleted in a year ;-)
I don't think we can do it all with dlopen(). Even when we have shared libraries for all the packages and the RTS, so we could use dlopen() to load those, we still need to be able to link plain .o files. I suppose dlopen() migth be able to load ordinary .o files these days, but it probably won't populate its symbol table with symbols from the .o unless it was linked with --export-dynamic or something. Cheers, Simon
Hello, On Monday 08 September 2008 14:22, Simon Peyton-Jones wrote:
Dear BDS hackers
We'd like GHC to be buildable on BSD, but at the moment it isn't. We support GHC on Linux, Windows, Mac, but we really need help with BSD.
I would like to do something about this. I have (a number of) x86s that either have some FreeBSD version installed or could get such an installation without too much trouble. The easiest one has an (admittedly old) 5.4 FreeBSD installed, that machine is running at the moment, it has actually managed to build
tn@tn21$ compiler/stage2/ghc-inplace --version The Glorious Glasgow Haskell Compilation System, version 6.9.20080517
using
tn@tn21$ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.4.1
and
tn@tn21$ compiler/stage2/ghc-inplace --interactive GHCi, version 6.9.20080517: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude> 2+2 4
works sometimes, but validate is a catastrophy (this is a dormant project). Another machine has some FreeBSD 6.x (I haven't checked), but I don't think it has any GHC running on it at the moment. A third possibility would be to take the latest (7.0) FreeBSD and install that. So, it would be useful to know, which FreeBSD version would you prefer to use for this?
...
Best regards Thorkil
On Mon, Sep 08, 2008 at 10:08:27PM +0200, Thorkil Naur wrote:
take the latest (7.0) FreeBSD and install that.
So, it would be useful to know, which FreeBSD version would you prefer to use for this?
I think that it's most important to get GHC working in the latest version, so from your message it sounds like 7.0 is the way to go. Thanks Ian
On Fri, Sep 12, 2008 at 5:13 AM, Ian Lynagh
On Mon, Sep 08, 2008 at 10:08:27PM +0200, Thorkil Naur wrote:
take the latest (7.0) FreeBSD and install that.
So, it would be useful to know, which FreeBSD version would you prefer to
use
for this?
I think that it's most important to get GHC working in the latest version, so from your message it sounds like 7.0 is the way to go.
I believe that a majority (or at least a plurality) of FreeBSD users are on 6.x still, as indicated by statistics on this page http://www.daemonology.net/portsnap/stats.html
Thanks Ian
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Quoth "Philip Weaver"
On Mon, Sep 08, 2008 at 01:22:15PM +0100, Simon Peyton-Jones wrote:
We'd like GHC to be buildable on BSD, but at the moment it isn't. We support GHC on Linux, Windows, Mac, but we really need help with BSD.
The current plans for OpenBSD (and I can only speak for OpenBSD here) are to provide a separate port/package with a trimmed down GHC 6.6.1 and use this to bootstrap GHC 6.10. This allows us to get a clean build without HC bootstrapping (and without ugly hacks like having to download a precompiled binary for bootstrapping). And we'll recycle the the 6.6.1 port once HC bootstrapping works again.
Alas, we didn't get much response to Simon's message below. (One, I think -- thank you to that person! I think it was Kili, but I'm not sure.)
I'm not sure, either. For the GHCi problem with mremap: well, it wouldn't be a catastrophic failure if it can't be fixed for the GHC 6.10 release, IMHO. We already had a broken GHCi on amd64 in the past (due to some real stupidity on my side, for which Don helped out), and the number of complaints I got was rather small ;-) BTW: I've only an i386 here, so fixing bugs happening on amd64 is difficult.
So this message is to say: if you'd like GHC on BSD, please help! No help probably means no GHC. Time is short before GHC 6.10.
If it isn't completely broken and just has some annoyances and bugs, you don't have to despair if bug fixes don't happen before the release. And at least on i386, the current GHC (6.9.20080908) can be built from GHC 6.6.1 up to stage2, and a second GHC can be built with this first build (I've still some problem with the make logic when trying to install this second build, but that's probably a PEBCAK). GHCi seems work fine, too. Any bugs hitting the release can be fixed for us (OpenBSD) after the release. Either upstream, in your repository, or, should any necessary fixes be too intrusive for other platforms, as simple patches in our ports tree. I may sound like a lazy slacker, but unfortunately I've just not enough spare time to work on GHC. And given the frustration I had during the last months, I'll also pass maintainership of our official GHC related ports to someone else, but I'll work on GHC head instead; doing both at the same time just isn't possible for now. Ciao, Kili ps: OpenBSD-4.4 will ship in october, with still GHC 6.6.1; we've time until feburary 2008 to get GHC 6.10 ready to with OpenBSD-4.5.
participants (7)
-
Donn Cave -
Ian Lynagh -
Matthias Kilian -
Philip Weaver -
Simon Marlow -
Simon Peyton-Jones -
Thorkil Naur