Bug 82541

Summary:	ghci b0rked on AMD64
Product:	Gentoo Linux	Reporter:	Luke Maurer (Jyrinx) <Luke.Maurer>
Component:	[OLD] Development	Assignee:	Gentoo's Haskell Language team <haskell>
Status:	RESOLVED FIXED
Severity:	major	CC:	amd64
Priority:	High
Version:	unspecified
Hardware:	AMD64
OS:	Linux
Whiteboard:
Package list:		Runtime testing required:	---

Description Luke Maurer (Jyrinx) 2005-02-19 01:18:09 UTC

When I emerge ghc-bin, ghc seems to work but ghci doesn't (see error below). In fact, ghc is functional enough for "emerge ghc" to work, and the resulting new from-source ghc works but ghci still doesn't:

---

jyrinx@mythrilspoon ~ $ ghci
   ___         ___ _
  / _ \ /\  /\/ __(_)
 / /_\// /_/ / /  | |      GHC Interactive, version 6.2.2, for Haskell 98.
/ /_\\/ __  / /___| |      http://www.haskell.org/ghc/
\____/\/ /_/\____/|_|      Type :? for help.

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

Please report it as a compiler bug to glasgow-haskell-bugs@haskell.org,
or http://sourceforge.net/projects/ghc/.

---

Other distros don't appear to have this problem, though the forums suggest some other Gentoo users are. This has been happening for months (though GHC at several points hasn't worked at all :-) ...)

Reproducible: Always
Steps to Reproduce:




jyrinx@mythrilspoon ~ $ emerge info
Portage 2.0.51-r15 (default-linux/amd64/2004.3, gcc-3.4.3,
glibc-2.3.4.20041102-r0, 2.6.10-gentoo-r7 x86_64)
=================================================================
System uname: 2.6.10-gentoo-r7 x86_64 AMD Athlon(tm) 64 Processor 3200+
Gentoo Base System version 1.6.9
Python:              dev-lang/python-2.3.4-r1 [2.3.4 (#1, Feb 13 2005, 17:00:56)]
dev-lang/python:     2.3.4-r1
sys-devel/autoconf:  2.13, 2.59-r6
sys-devel/automake:  1.7.9-r1, 1.5, 1.9.4, 1.6.3, 1.4_p6, 1.8.5-r3
sys-devel/binutils:  2.15.92.0.2-r2
sys-devel/libtool:   1.5.10-r4
virtual/os-headers:  2.6.8.1-r3
ACCEPT_KEYWORDS="amd64 ~amd64"
AUTOCLEAN="yes"
CFLAGS="-O3 -pipe -fomit-frame-pointer"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.2/share/config
/usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown
/usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref
/usr/share/config /usr/share/texmf/dvipdfm/config/
/usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/
/usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/
/var/lib/games/*.scores /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/X11/app-defaults /etc/gconf /etc/gconf/schemas/
/etc/init.d/ /etc/sound/events/ /etc/terminfo /usr/X11R6/lib/X11/xkb /etc/env.d"
CXXFLAGS="-O3 -pipe -fomit-frame-pointer"
DISTDIR="/var/portage/distfiles"
FEATURES="autoaddcvs autoconfig ccache distlocks nostrip"
GENTOO_MIRRORS="ftp://mirrors.tds.net/gentoo http://gentoo.mirrors.pair.com/"
LANG="en_US.utf8"
LC_ALL="en_US.utf8"
MAKEOPTS="-j2"
PKGDIR="/var/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/var/portage"
PORTDIR_OVERLAY="/usr/local/var/portage /home/jyrinx/var/portage"
SYNC="rsync://rsync.us.gentoo.org/gentoo-portage"
USE="amd64 X acpi aim alsa audiofile avi bash-completion berkdb bitmap-fonts
blas bonobo bzlib cdb cdr crypt ctype cups curl dba divx4linux dvd dvdr dvdread
encode esd f77 fam fbcon flac flash font-server fortran ftp gb gd gif gnome gpm
gstreamer gtk gtk2 hal icq imap imlib ipv6 java javascript jp2 jpeg ladcca
libgda libwww lzw lzw-tiff ming mng motif mozilla mpeg multilib mysql ncurses
nls nptl offensive oggvorbis openal opengl pam pcre pda perl php png pnp python
readline samba slp sockets socks5 spell ssl svg tcpd tetex theora tiff truetype
truetype-fonts type1-fonts unicode usb userlocales wmf wxwindows xml2 xosd xpm
xprint xrandr xv xvid zlib"
Unset:  ASFLAGS, CBUILD, CTARGET, LDFLAGS

Comment 1 Ryan Lortie 2005-02-19 08:43:52 UTC

the RTS needs to be ported to AMD64.  this is being worked on upstream.  it probably won't be in 6.4 but it's a candidate for 6.4.1.

this is not gentoo's problem or something that gentoo can reasonably fix.

what can be done though is to add "GhcWithInterpreter=NO" to mk/build.mk on AMD64.  this will cause it to give a somewhat nicer "not built for interactive use" message when you run ghci.

Comment 2 Luke Maurer (Jyrinx) 2005-02-19 11:52:01 UTC

Hrm ... yeah, I just reread the report I found of ghci working on an AMD64 box ... I failed to realize it only worked because the guy was installing it as a 32-bit i386 app (after installing 32-bit gmp and readline to go with it).

In the meantime, is there any simple way to use multilib and/or emul-linux-x86-* stuff to have emerge build a 32-bit ghc and ghci that'll work, albeit handicapped?

Comment 3 Ryan Lortie 2005-02-19 12:00:00 UTC

GHC looks at the uname output to determine what platform it's going to build for so I can't think of an easy way to build for i386 on an AMD64 box (without playing with the build system a little bit, anyway).

I recommend just installing the binary package for i386.  That should work.  You can probably convince 'emerge ghc-bin' to do it with some minor ebuild hacking.

BTW: For GHC, i386 performance will actually exceed amd64 performance (i386 is more fully registerised) so it's not handicapped to use the 32bit packages.

Comment 4 Simon Stelling (RETIRED) gentoo-dev

2005-05-04 02:56:37 UTC

i don't know why this bug is still open, using ghc-bin seems to be a reasonable solution