Bugzilla Bug 58588

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 an attachment (id=36287) [edit]
The sacred ebuild that enables unregisterised build on amd64

Created an attachment (id=36327) [edit]
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 an attachment (id=36474) [edit]
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 an attachment (id=39044) [edit]
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 an attachment (id=42095) [edit]
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 an attachment (id=42267) [edit]
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