Bugzilla Bug 143141

I've upgraded the existing ebuild to work with hugs98-plus-May2006 (2006.5).

Please note that hugs is really strict about CFLAGs; the compilation breaks
even when using something as innocent as -march. I've added an ewarn-ing about
that.

Created an attachment (id=93693) [edit]
ebuild

Created an attachment (id=93694) [edit]
find patch

(In reply to comment #0)
> I've upgraded the existing ebuild to work with hugs98-plus-May2006 (2006.5).

Thanks Anakim.

> Please note that hugs is really strict about CFLAGs; the compilation breaks
> even when using something as innocent as -march. I've added an ewarn-ing about
> that.

Hmm, that's not so good as many arches really do need to use that (or -mcpu).
Sparc is an exmple of this.

Perhaps you/we can investigate what's going on with flags like -march. I'm
afraid I've not had time to look yet, how does it break with -march?

> Perhaps you/we can investigate what's going on with flags like -march. I'm
> afraid I've not had time to look yet, how does it break with -march?

I'm attaching the full compilation log.

It seems like -march is interfering with the build of "runhugs". As soon as the
resulting executable is run, it stops with an "INTERNAL ERROR: discrArity".

There's no trace of such a problem in the Hugs bug tracker
(http://hackage.haskell.org/trac/hugs)

Searching the sources, I found the definition of the discrArity function
(src/compiler.c, line 1544):

Int discrArity(d)                      /* Find arity of discriminator      */
Cell d; {
    switch (whatIs(d)) {
        case NAME      : return name(d).arity;
        case TUPLE     : return tupleOf(d);
        case CHARCELL  : return 0;
#if TREX
        case AP        : switch (whatIs(fun(d))) {
#if NPLUSK
                             case ADDPAT : return 1;
#endif
                             case EXT    : return 2;
                             default     : return 0;
                         }
#else
#if NPLUSK
        case AP        : return (whatIs(fun(d))==ADDPAT) ? 1 : 0;
#else
        case AP        : return 0;      /* must be an Int or Double lit    */
#endif
#endif
    }
    internal("discrArity");
    return 0;/*NOTREACHED*/
}

internal() gets called because whatIs(d) it's returning an unexpected value.
One could trace through that function with a debugger and compare its behavior
with and without -march...

As a last note, something I forgot to mention erlier. I'm actually using gcc
4.1.1; unfortunately at this time I have no way to test the ebuild on an older
3.something version.

Created an attachment (id=93794) [edit]
full compilation log, showing runhugs internal error

Thanks very much Anakim for your detailed report.

Hi Anakim,

which CFLAGS and and platform where you using when it broke?

I just successfully compiled your ebuild on x86 with
CFLAGS="-O2 -march=pentium4 -fomit-frame-pointer -pipe"

> which CFLAGS and and platform where you using when it broke?

Portage 2.1-r2 (default-linux/x86/2006.0, gcc-4.1.1, glibc-2.4-r3,
2.6.17-gentoo-r4 i686)
=================================================================
System uname: 2.6.17-gentoo-r4 i686 AMD Athlon(tm) XP
Gentoo Base System version 1.12.4
app-admin/eselect-compiler: [Not Present]
dev-lang/python:     2.4.3-r1
dev-python/pycrypto: 2.0.1-r5
dev-util/ccache:     [Not Present]
dev-util/confcache:  [Not Present]
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2
sys-devel/binutils:  2.16.1-r3
sys-devel/gcc-config: 1.3.13-r3
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.11-r5
ACCEPT_KEYWORDS="x86"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-march=athlon-xp -msse -O2 -pipe -fomit-frame-pointer -ftracer"
CHOST="i686-pc-linux-gnu"
CXXFLAGS="-march=athlon-xp -msse -O2 -pipe -fomit-frame-pointer -ftracer"

Since -ftracer is not completely safe, I disabled it before emerging hugs. But
even that was not enough: I had to trim CFLAGS down to "-O2".

*** Bug 159110 has been marked as a duplicate of this bug. ***

Does the problem described above still exist in hugs98-plus-Sep2006?

> Does the problem described above still exist in hugs98-plus-Sep2006?

I was able to compile hugs98-plus-Sep2006 successfully without changing CFLAGS.
Seems like the problem has been fixed.

*** Bug 197224 has been marked as a duplicate of this bug. ***

Created an attachment (id=134498) [edit]
the new ebuild. Works for me.

I posted this in the bug that was just marked duplicate, but since no-one reads
duplicate bugs, I'm reposting the new ebuild here.

The change from 2005.3-r2 ebuild is basically this:

diff /usr/portage/dev-lang/hugs98/hugs98-2005.3-r2.ebuild
/usr/local/portage/dev-lang/hugs98/hugs98-2006.9.ebuild --unified
--- /usr/portage/dev-lang/hugs98/hugs98-2005.3-r2.ebuild        2007-07-22
11:35:34.000000000 +0200
+++ /usr/local/portage/dev-lang/hugs98/hugs98-2006.9.ebuild     2007-10-27
18:54:01.745041793 +0200
@@ -31,14 +31,15 @@
 HUGS_MONTH=$(transform_month ${HUGS_MONTH_NR})
 MY_PV="${HUGS_MONTH}$(get_major_version )"
 MY_P="${PN}-${MY_PV}"
+MY_DIR=$(printf "%4d-%02d" $(get_major_version) ${HUGS_MONTH_NR})
 S=${WORKDIR}/${MY_P}
 DESCRIPTION="The Hugs98 Haskell interpreter"
-SRC_URI="http://cvs.haskell.org/Hugs/downloads/${MY_PV}/${MY_P}.tar.gz
-               
http://cvs.haskell.org/Hugs/downloads/${MY_PV}/${MY_P}-patch.gz"
+SRC_URI="http://cvs.haskell.org/Hugs/downloads/${MY_DIR}/${MY_P}.tar.gz"
+#              
http://cvs.haskell.org/Hugs/downloads/${MY_DIR}/${MY_P}-patch.gz"
 HOMEPAGE="http://www.haskell.org/hugs/"

 SLOT="0"
-KEYWORDS="alpha amd64 hppa ia64 ~mips ppc ppc64 sparc x86 ~x86-fbsd"
+KEYWORDS="alpha amd64 hppa ia64 ~mips ppc ppc64 sparc ~x86 ~x86-fbsd"
 LICENSE="as-is"

 RDEPEND="
@@ -55,9 +56,9 @@
 src_unpack() {
        base_src_unpack
        cd ${S}
-       epatch ${WORKDIR}/${MY_P}-patch
-       epatch ${FILESDIR}/${P}-openal.patch
-       epatch ${FILESDIR}/${P}-find.patch
+#      epatch ${WORKDIR}/${MY_P}-patch
+#      epatch ${FILESDIR}/${P}-openal.patch
+#      epatch ${FILESDIR}/${P}-find.patch

        if ! use X; then
                sed -i -e 's/X11//' -e 's/HGL//' "${S}/Makefile" \

Now in portage.