With the attached ebuild, dev-lang/ghc-6.2.1-r2 works on amd64. The ebuild enables unregisterised build on architectures other than x86 or ppc, so it might be useful for other architectures than amd64 too. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 36287 [details] The sacred ebuild that enables unregisterised build on amd64
Created attachment 36327 [details] A script to create a binary distribution of ghc-amd64 suitable for bootstrapping The script will create a tmp directory for itself and won't touch anything else. Requirements: dpkg, internet connection (to fetch the debian package)
Created attachment 36474 [details] dev-lang/ghc-deb-6.2.1 This ebuild installs the debian package of ghc in /opt/ghc, in order to emerge dev-lang/ghc-6.2.1-r2.
After installing ghc-deb I get the following error # /opt/ghc/bin/ghc ghc-6.2.1: Can't find package.conf as /opt/ghc/lib/ghc/driver/package.conf.inplace
I assume you've patched the ghc-deb ebuild to get ghc6-6.2.1-5, the ebuild I posted works, but the .deb is no longer available. dev-lang/ghc-deb-6.2.1-r1 follows.
Created attachment 39044 [details] dev-lang/ghc-deb-6.2.1-r1
Unfortunately I always get the following error when I trying to compile all but the simplest programs: ghc-6.2.1: internal error: getMBlock: mmap: Invalid argument Please report this as a bug to glasgow-haskell-bugs@haskell.org, or http://www.sourceforge.net/projects/ghc/ This is exactly the same error I got when I tried to make an unregistered build myself. Does it work for you?
> Unfortunately I always get the following error when I trying to compile all but the simplest programs: Could you please post an strace, the output of emerge info and the program you're trying to compile?
Ok forget what I wrote above it seems to work now :-) regards
Committed as ghc-bin. Thanks
First of all, thank you for commiting the binary ebuild. What was the reason you didn't commit the (actual) ghc ebuild with support for unregisterised compilation? - Do you dislike the is_unregisterised function? - Do you want a 6.2.2 version? - Do you want a patch rather than a full ebuild? I'd be happy to change it if you don't like something.
Actually the fact is I don't know anything about Haskell, I'm just trying to find what works and get these Haskell-related bugs out of our queue. I smacked that ebuild together out of yours, partially. Don't ask me why, it was late. :) I don't understand your comment about unregistered compilation. I tore out anything that I didn't understand. But, in any case, binary ebuilds belong in ghc-bin, not ghc. We need to have dev-lang/ghc-bin up first before we can tackle a source build. Correct me if I'm wrong here. So, assuming that people use the new ebuild, the next step is to bootstrap a runtime in dev-lang/ghc using the runtime supplied by ghc-bin. From there, I don't know how a system makes the distinction between the two. I need input from people who know how Haskell is supposed to work so that we can get it going on amd64. I have CC:'d kosmikus.
Ok, so you didn't find the ebuild. I'll repost it now. Actually, the source ebuild is what the actual purpose of this bug was.
Created attachment 42095 [details] dev-lang/ghc-6.2.2 ebuild with support for unregisterised compilation (needed on amd64)
I've got in issue with ghc-bin-6.2.1.ebuild. It merges happily on my AMD64 box, but when I run GHCi: --- jyrinx@mythrilspoon ~ $ ghci [...] Loading package base ... /opt/ghc/lib/HSbase.o: unknown architecture ghc-6.2.1: panic! (the `impossible' happened, GHC version 6.2.1): loadObj: failed --- I'm not sure what's up ... I'd suspect multilib, which I only recently got (mostly) working, but of course I didn't compile these binaries ... (Sorry if this is the wrong place ... should I file a new bug?)
Re #15: As far as I can see it, there are only unregistered builds for ghc on amd64 at the moment. This means, among other things, that ghci won't work. Thus, to my knowledge, this isn't a bug, but expected behaviour, as strange as it seems ... ks
Heh ... you're right ... I was assuming that ghci works iff ghc works, especially since the error looked like it was coming from ghc. Ah, well.
Created attachment 42267 [details] dev-lang/ghc-6.2.2-r1 This ebuild is based on the 6.2.2 ebuild in portage, so you'll need to put ghc-6.2.hardened.patch in files/ if you put this ebuild into PORTDIR_OVERLAY. I'm currently emerging this ebuild, so it might not work, but I'll post again when I've tested it.
ghc-6.2.2-r1 works well. darcs compiles and runs happily.
I'm currently working on zhen's dev box to get this working. Things look positive and I should have a ghc-src ebuild up. I pretty much used Gabriel's ebuild in order to achieve this. If anyone else on haskell herd things there's a better way to do this, let me know, otherwise I'll keep working with the unregistered technique. I'm also doing this for a couple other arches including ppc and sparc, thus said, I'll soon be tying this to another bug # for the other arches and amd64. ghc-6.2.2-r1 will be the version, but for testing purposes it will be package.masked and amd64 keywords will be missing until I can get an amd64 dev to KEYWORD it. Once that's done, you guys should be pretty much ok to unmask it and let er go :). I also plan on using zhen's box to make some binaries for ghc 6.2.2 so that you guys don't have such outdated binary versions (I think amd64 uses 5.04 as their only valid ghc-bin version), and the binaries will be a true Gentoo tbz binary package. This sould make things a tad cleaner without having to worry about depending on .debs left and right. I hope this clears things up :).
> Things look positive and I should have a ghc-src ebuild up. I just hope it's still called 'dev-lang/ghc'. > so that you guys don't have such outdated binary versions (I think amd64 uses 5.04 as their only valid ghc-bin version) AFAIK, ghc-5.04 doesn't even work on amd64. The current ghc-bin version for amd64 is 6.2.1 (from debian). > and the binaries will be a true Gentoo tbz binary package. Does that have any advantages over the current approach? Currently building ghc from source is as easy as emerge ghc. With your proposal, you'd need to download ghc-6.2.2-r1.tbz2, emerge it, and then emerge ghc, wouldn't you?
The source ebuild will still be called dev-lang/ghc. Fact is, the versions of the binaries are currently very different depending on architecture. I agree with chriswhite that we should get 6.2.2 up and running for as many archs as possible. With the "true Gentoo binary package", I'm not sure what chriswhite means exactly either. I definitely think ghc-bin should stay. Where the archive containing the binary comes from and how it is built, is open for debate, though. ks
Hi! I cannot emerge ghc on amd64. It fails with the sandbox violation (like haddock - see #69830): [..] ===fptools== Recursively making `install' in includes utils driver docs compiler rts ... PWD = /var/tmp/portage/ghc-6.2.2-r1/work/ghc-6.2.2/ghc ------------------------------------------------------------------------ ------------------------------------------------------------------------ ==fptools== make install -wr; in /var/tmp/portage/ghc-6.2.2-r1/work/ghc-6.2.2/ghc/includes ------------------------------------------------------------------------ mkdir //usr/lib/ghc-6.2.2 ACCESS DENIED mkdir: /usr/lib/ghc-6.2.2 mkdir: cannot create directory `//usr/lib/ghc-6.2.2': Permission denied mkdir //usr/lib/ghc-6.2.2/include ACCESS DENIED mkdir: /usr/lib/ghc-6.2.2/include mkdir: cannot create directory `//usr/lib/ghc-6.2.2/include': Permission denied make[2]: *** [install] Error 1 make[1]: *** [install] Error 1 make[1]: Leaving directory `/var/tmp/portage/ghc-6.2.2-r1/work/ghc-6.2.2/ghc' make: *** [install] Error 1 !!! ERROR: dev-lang/ghc-6.2.2-r1 failed. !!! Function src_install, Line 179, Exitcode 2 !!! make install failed I'm really wondering how does it work for you? Sincerely, Gour
In the debian-based ghc-bin-6.2.1 ebuild, the ghc-pkg program was not installed properly to /opt/ghc/bin. I've added two symlinks. I'm not sure whether this is the only problem with the ebuild, though. Re Gour's problem: I'm not sure what causes this atm -- all I can say is I cannot reproduce it on x86, and that I need more information ... ks
I've tried the ghc-6.2.2-r1 ebuild from this bug. It builds fine, either from itself or from ghc-bin-6.2.1, but ghc and ghci don't work for different reasons: jyrinx@mythrilspoon portage $ ghci [...] Loading package base ... //usr/lib/ghc-6.2.2/HSbase.o: unknown architecture ghc-6.2.2: panic! (the `impossible' happened, GHC version 6.2.2): loadObj: failed --- jyrinx@mythrilspoon dicedist $ ghc --make Dicedist.hs Chasing modules from: Dicedist.hs ghc-6.2.2: internal error: getMBlock: mmap: Invalid argument --- Incidentally, a simple one-line "Hello World" compiles and runs fine. (I can provide emerge --info and such if needed; didn't want to clutter the bug)
Hi! > Re Gour's problem: I'm not sure what causes this atm -- all I can > say is I cannot reproduce it on x86, and that I need more information ... Just to inform you that after resolving some nptl/prelink issues, dev-lang/ghc-6.2.2-r1 ebuild emerges on amd64 with the same patch as for haddock, i.e. adding "libdir0="${D}/usr/$(get_libdir)" \" in the src_install () function and I just compiled darcs without any problem. Let's add some '~amd64' to Gentoo-Haskell department :-) Sincerely, Gour
This works for me as well on amd64, WITH the patch that was needed for Haddock. Otherwise I get a sandbox violation. I have compiled and run darcs and some own code on this build, and they work as expected.
ghc-6.2.2 is now ~amd64. Cheers, ks
i think we can close this bug
As far as I can see the ebuild does not set GhcUnregisterised=YES in mk/build.mk. Do newer ghc's contain a ./configure check to enable the unregisterised build?
You're right of course. Should be fixed in CVS now. Thanks. ks
