Simon Marlow
So, try the patch to get the patch to compile against ghc 6.8.3-snapshot, and see if it works on OpenBSD?
It's not just a case of testing the patch, there are a couple of issues to address:
- it has a couple of wired-in addresses: one place to load object files, another to put jump tables at. This is necessary because *BSD doesn't have the MAP_32BIT flag for mmap(). However, the particular wired-in addresses needed will probably vary on the different *BSDs. Someone needs to look at the memory map and make sure we're picking sensible addresses.
It is not very likely that the adresses change between *BSDs because they are resulting from simple hardware-related constraints. Though, a test is necessary. OTOH, has anybody from the GHC team asked the *BSD developers to add a MAP_32BIT flag already? I know that these people are very reluctant to change requests, this one may find their mercy if the right persons ask for it.
- the patch doesn't #ifdef its changes, so it'll break other platforms (easy to fix).
I looked into the patch, and it doesn't look as if it would break other platforms, as the changed code is inside proper ifdefs mostly. Some parts may be superfluous. The easiest check is to compile the FreeBSD-patched code under one of the other platforms (are there other than Linux and OSX?). In any case, the ifdef'ing can be automated using diff with -D__FreeBSD__ option.
Also the code has changed in HEAD, and we need a completely different patch there (although the same idea applies, pick an address and use MAP_FIXED).
This is, of course, the most significant problem for GHC, but probably not relevant to this special release process. It is better to include the patch than to leave it out (provided that I am right resp. to the breaking of otherplatforms). -- Dipl.-Math. Wilhelm Bernhard Kloke Institut fuer Arbeitsphysiologie an der Universitaet Dortmund Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-373 PGP: http://vestein.arb-phys.uni-dortmund.de/~wb/mypublic.key