| Summary: | Getting ghc ported to various arches | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Chris White (RETIRED) <chriswhite> |
| Component: | Current packages | Assignee: | Gentoo's Haskell Language team <haskell> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | haskell, plasmaroo, vapier |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 72747 | ||
| Bug Blocks: | |||
| Attachments: |
Patch to be applied against 6.2.2 to enable splitobjs
Patch to the ghc-6.2.2 ebuild ghc-bin-6.2.2.ebuild ghc-bin-6.2.2.ebuild |
||
|
Description
Chris White (RETIRED)
2004-10-25 23:25:42 UTC
Being more specific on what compiler I'm talking about would be nice :). ghc 6.2.2 runs fine on powerpc gentoo. It would be nice if the ghc-bin installer supported this. I have an iBook so I can probably get this working in the next few days. The ghc source build disables SplitObjs on powerpc due to lack of support. I've added SplitObjs support to GHC CVS HEAD and am including a backported patch for it here (that should apply against 6.2.2 source.) This will remove the need for the SplitObjs=NO hack (which reduces the size of a compiled "Hello World" program by a factor of 5) Created attachment 42625 [details, diff]
Patch to be applied against 6.2.2 to enable splitobjs
This patch should be copied into the files/ directory and applied while
building ghc from source on powerpc (although it won't effect other arch's.)
Then the SplitObjs=NO hack should be remove from the ebuild.
Created attachment 42627 [details, diff]
Patch to the ghc-6.2.2 ebuild
This patch applies to the ghc-6.2.2 ebuild and expects the previous patch to be
in the files/ directory as "ghc-6.2-powerpc-splitobjs.patch"
Great, because ppc was my next target since I have amd64 and sparc good to go. It will not, however, get rid of SplitObj entirely, as amd64 needs it. But thanks a ton for getting a patch out for ppc. You won't see results right away, as I'm going to take this on for all arches, and just pull one final ebuild will all ghc-bin's ready for everyone. This should very much simplify the process. Sure, there should be one ghc-bin for all arches. However, the patch is for the ghc ebuild, not for ghc-bin, and could be applied more or less immediately, *if* it works on ppc, which I cannot test. ks 1) I've tested my SplitObjs patch outside of portage and it works, but I've never actually typed "emerge ghc" and watched it complete successfully with my patch. I'm going to do this tonight (it takes 3.5 hrs to build on my iBook) and I'll let you know in the morning if it succeeded. 2) My contribution to the ghc-bin effort is uploaded here: http://manic.desrt.ca/ghc/ghc-6.2.2-powerpc-unknown-linux-splitobjs.tar.bz2 (md5 1ba193a06fa0b80dfa8e3f909763c756). kosmikus thinks that there should probably be a note in the ebuild explaining why we're not using the official 6.2.2 binary. Something along the lines of: # We don't use the official ghc-6.2.2 binary distribution. The splitobjs # patch (which was applied to CVS shortly after 6.2.2 was released) results # in "Hello World" being being 5 times smaller on powerpc, so we want this. 3) I should be able to get SplitObjs working properly on AMD64 if your friend with the devbox comes through with an account for me :) * If you have dev-lang/ghc-bin installed, you might * want to unmerge it again. It is no longer needed. >>> Regenerating /etc/ld.so.cache... * Caching service dependencies... >>> dev-lang/ghc-6.2.2 merged. >>> Recording dev-lang/ghc in "world" favorites file... It works, and the resulting ghc is producing quite small binaries. http://manic.desrt.ca/ghc/ghc-6.2.2-powerpc64-unknown-linux.tar.bz2 Here's a binary package for ppc64. It's unregistered and ghci is unsupported. No SplitObjs either. I'm fairly certain that that registered ppc64 builds or ghci on ppc64 will never be supported on 6.2 (and I don't plan to add this support myself.) They will be supported some time on the 6.4 branch, though. Sorry, only just noticed this report (after filing bug #72747). Has there been any progress on linux sparc64 that I can test and hack on? I'd start with the debian sparc port but if someone already has something closer then I'll start from that. For sparc, I can report that installing the debian 6.2.1 version works nicely, you just unpack it, move everything into /usr/local and fix up a couple scripts so they use the right directories and everything works (so far). I can then emerge the latest ghc-6.2.2 ebuild. The only modification was to turn off splitobjs for sparc. It bootstraps ok but on installation, ghci doesn't work properly (the debian package's ghci did work). ghci complains: /usr/lib/ghc-6.2.2/HSbase_cbits.o: unknown symbol `__muldi3' ghc-6.2.2: unable to load package `base' This symbol appears to be the same in the debian version and the version I built. So I'm not sure yet whats going on there. I'll check if the debian build does anything differently from our ebuild. Created attachment 45604 [details]
ghc-bin-6.2.2.ebuild
Modified full ebuild for ghc-bin for ppc64
Created attachment 45605 [details]
ghc-bin-6.2.2.ebuild
Ok, this one is better, as ghc now has a whole bunch o bins for arches on their
site :P.
Sparc, ppc64, ppc: I have an ebuild attached that simply adds SRC_URI's for the various arches and puts unstable keywords (no, this hasn't been commited to the tree :P). Can you please test this and let me know if you run into any issues? If not, please add your appropriate SRC_URI to the ebuild and mark it. Here's something I don't understand: is gentoo suppoed to work on sparc solaris or something? The SRC_URI for sparc is for solaris. It certianly does not work for sparc linux. On the other hand I can provide a ghc-bin ebuild to get the debian binary package to work correctly on sparc linux. With one patch, I should (just testing it now) be able to get the ghc source ebuild to work correctly in which case I could provide a binary package produced by portage. Can on of these binary packages be turned into a ghc-bin ebuild easily? I've not seen any *-bin ebuilds that do this. Using portage-produced binary packages for the ghc-bin ebuilds is certainly possible, maybe even preferable, because we could do this for all architectures. I don't particularly like installing .deb's ... ks And it could work with a single ghc-bin ebuild (with arch specific SRC_URI). At the moment we have various versions of ghc-bin ebuilds, some of them just for a single arch (see ghc-bin 6.2.1 for example). At the moment it would be hard to combine them, since they do fairly different things (some download a .deb, others download a tar.gz from haskell.org). Right. Not impossible, but hard and probably confusing. So we'd start from the binpkg that is produced by the normal, bootstrapped, dev-lang/ghc ebuild, right? If you want to produce an ebuild and a couple of packages to start with, we could put it on the servers, hardmasked, for testing. I still dream of bootstrapping from .hc, though ;) But the other approach is the next best thing, and -- if I understand correctly -- was also chriswhite's original plan when opened this bug. ks Here's something I don't understand: is gentoo suppoed to work on sparc solaris or something? The SRC_URI for sparc is for solaris. It certianly does not work for sparc linux. Hence why I was asking for testing. In fact, the main reason why I decided to try it out was because an earlier ghc ebuild used the sparc-solaris version, not a sparc-linux version. As far as the plan I'm trying to get at, I'd like to have ghc bin versions on 6.2.2, and try and get that into stable, so we don't have a number of ebuilds with random arches marked across the board. I'd like everyone to be using the same ~arch/arch ebuild so that it's easier to approach bugs and security updates. As far as the ghc-6.2.2 ebuilds, those will be approached by using the new ghc-bin ebuilds, and bootstrapping that way. By doing this, I hope to get the arches using one version that's easily bump-able and more manageable. I hope this explains what I'm trying to do clearly. Re sparc: I'd assume that even if it is in one of the old ebuilds (which I can confirm), it is most probably a bug and should be removed. chriswhite, about your plan: yes, but wouldn't the best way to achieve this is to try to build the non-binary ghc ebuild on each platform and then create a binary package out of that build, which would be comparable (modulo (un)registered-ness) for all platforms? This way, we can in principle support more architectures than the GHC developers do directly, and also reach more uniformity, as the binary packages on the GHC site aren't necessarily all built with comparable options ... One more note: according to Simon Marlow (spoke with him last week), GHC 6.4 is still planned to be released before the end of the year. ks > In fact, the main reason why I decided to try it out was because an earlier > ghc ebuild used the sparc-solaris version, not a sparc-linux version. Oh, ok. Yes I don't think it has ever worked for sparc. I think it is certianly a good idea to be using the same version of ghc-bin across all platforms. I imagine a ebuild to install a portage-built binary package would not be too hard. Then it's just a matter of doing a build for each platform and uploading the file. I'll take sparc. BTW: take a look at the debian patch for ghc-6.2.2. Ian has it working for loads of platforms on debian: http://ftp.uk.debian.org/debian/pool/main/g/ghc6/ghc6_6.2.2-2.diff.gz It has some extra debian-specific files but you can ignore those. They've got patches for aplha, hppa, sparc. There's a bunch of chages that seem to be just about install locations which we can ignore. I have ghc-6.2.2 working on sparc. It just required the following patch (from the debian patchset):
--- ghc6-6.2.2.orig/ghc/rts/Linker.c
+++ ghc6-6.2.2/ghc/rts/Linker.c
@@ -592,6 +592,7 @@
Sym(__udivdi3) \
Sym(__moddi3) \
Sym(__umoddi3) \
+ Sym(__muldi3) \
Sym(__ashldi3) \
Sym(__ashrdi3) \
Sym(__lshrdi3) \
ghc-bin-6.4 and ghc-6.4 are now ~ppc64. corsair, I had to remove the ~ppc64 from ghc again (not ghc-bin), because ghc depends on haddock (and other packages) if USE="doc", and those are not ~ppc64 ... Could you please check if the dependencies can be compiled on ppc64, and then add the keywords everywhere if that's the case? Cheers, ks I've comitted ghc-bin-6.2.2-r1 with just ~sparc in the KEYWORDS, and added
~sparc to the KEYWORDS of the ghc-6.2.2 and haddock-0.6-r3 ebuilds.
The patch in #22 is not strictly necessary. It is needed for GHCi support but
GHCi always segfaults for me on 2.6 kernels (2.4 is fine), so I've disabled GHCi
support for the moment on sparc. Help debugging this problem would be apreciated.
The ghc-bin-6.2.2-r is based on the ghc-bin-6.4 ebuild which uses portage .tbz2
binary snapshots. Other arches should be added to this ebuild (and ghc-bin-6.4).
When creating the .tbz2 you need to make sure you build ghc with USE="-doc -java
-tetex -opengl". If you use emerge + quickpkg rather than "ebuild ghc-6.x.y
package" then make sure you have no packages other than the basic ones
registered, ie check that ghc-pkg -l gives just:
rts, base, haskell98, haskell-src, network, parsec, QuickCheck,
readline, unix, lang, concurrent, posix, util, data, text, net,
hssource
sparc is done here, we have ghc-bin-6.2.2-r1 & ghc-6.2.2 stable. ghc-bin-6.4 and ghc-6.4.1 are ~ppc, so removing ppc from cc. So we now build on: x86, amd64, sparc, ppc, ppc64 and (as of a few days ago) alpha. If we do want to go further, the debian folk seem to have ports for: hppa, ia64 and s390. However, I think this is as far as we are likely to get with the developer and hardware resources we have available to us. So I suggest we close this bug now, unless anyone wants to be more ambitious. We could CC the remaining arches to see if anyone there is remotely interested. Well, plasmaroo can hookup an ia64 dev box, and spanky has an hppa setup as well. s390.. spanky has one, but doesn't have it listed as a developer box. Up to you. But yah, the marking weirdness has definately gone away. I think we've come to the conclusion that we're happy with supporting the arches we've got. We would need interested helpers with access to hardware for any of the other archs. If anyone wants to volunteer to help us support ghc and other haskell ebuilds on another arch then do get in touch. I'm cc'ing plasmaroo and vapier just in case they are interested or know anyone who might be interested. If no one's interested I'll close this bug. if you need access to some architecture, see the dev-machines page: http://www.gentoo.org/proj/en/infrastructure/dev-machines.xml We've now got ppc64 working again and updated to ghc-6.4.1 and a ghc-bin-6.4.1 too. It's possible we might get hppa some time. We're not too interested at the moment in actively seeking out test machines but we are happy to have more arches if there are people out there who want to do the porting work. So I'm closing this bug. |