Build fails on Archlinux (64-bit)

[GoogleCodeExporter]

What steps will reproduce the problem?

Install inferno-os from the Archlinux AUR.  This is equivalent to a standard hg 
clone followed by the usual mk process.

The error occurs on my Macbook and my custom build PC.  Both have a current 
version of Archlinux 64-bit installed (latest packages as of today).  Using 
multilib repositories to build with 32-bit gcc/libs.

What is the expected output? What do you see instead?

Expected output - A working inferno environment.

What do I see - The following error during the build process:

cc -m32  -o o.out asm.o com.o decls.o dis.o dtocanon.o ecom.o gen.o lex.o 
nodes.o optab.o optim.o sbl.o stubs.o typecheck.o types.o y.tab.o 
/home/rje/src/aur/inferno-os/pkg/inferno-os/opt/inferno-os/Linux/386/lib/libbio.
a 
/home/rje/src/aur/inferno-os/pkg/inferno-os/opt/inferno-os/Linux/386/lib/libmath
.a 
/home/rje/src/aur/inferno-os/pkg/inferno-os/opt/inferno-os/Linux/386/lib/libsec.
a 
/home/rje/src/aur/inferno-os/pkg/inferno-os/opt/inferno-os/Linux/386/lib/libmp.a

/home/rje/src/aur/inferno-os/pkg/inferno-os/opt/inferno-os/Linux/386/lib/lib9.a 
rm -f 
/home/rje/src/aur/inferno-os/pkg/inferno-os/opt/inferno-os/Linux/386/bin/limbo 
&& cp o.out 
/home/rje/src/aur/inferno-os/pkg/inferno-os/opt/inferno-os/Linux/386/bin/limbo
(cd libinterp; mk  install)
rm -f runt.h && limbo -a -I../module ../module/runt.m > runt.h
sh: line 1:  7960 Floating point exception(core dumped) limbo -a -I../module 
../module/runt.m > $target
mk: rm -f runt.h ...  : exit status=exit(136), deleting 'runt.h'
mk: for j in ...  : exit status=exit(1)

Which operating system are you using?

Archlinux (64-bit) - latest packages as of 11PM Friday June 28th, 2013.

Please provide any additional information below.

There's nothing special about my system, at least I don't think so.  I would 
expect that the standard build process should work.

Thanks!
Rob

Original issue reported on code.google.com by rennis...@gmail.com on 29 Jun 2013 at 3:23

[GoogleCodeExporter]

Check this thread: http://thread.gmane.org/gmane.os.inferno.general/5639

Original comment by powerman...@gmail.com on 29 Jun 2013 at 3:43

[GoogleCodeExporter]

Thanks!  I'll keep an eye on it.  Glad to see that they're already close to a 
potential solution.

--Rob

Original comment by rennis...@gmail.com on 29 Jun 2013 at 4:38

[GoogleCodeExporter]

this simple patch should work (work for me)

--- a/makemk.sh Sat Sep 07 11:32:50 2013 +0100
+++ b/makemk.sh Tue Oct 08 16:56:43 2013 +0200
@@ -19,8 +19,14 @@
 PLAT=$ROOT/$SYSTARG/$OBJTYPE

 # you might need to adjust the CC, LD, AR, and RANLIB definitions after this point
-CC="p gcc -c -I$PLAT/include -I$ROOT/include -I$ROOT/utils/include"
-LD="p gcc"
+PLTFLAGS=""
+if  [ "$(uname -s -m)" == "Linux x86_64" ]
+then
+       echo HERE
+       PLTFLAGS="-m32"
+fi
+CC="p gcc $PLTFLAGS -c -I$PLAT/include -I$ROOT/include -I$ROOT/utils/include"
+LD="p gcc $PLTFLAGS"
 AR="p ar crvs"
 RANLIB=":"     # some systems still require `ranlib'

Original comment by bau...@gmail.com on 8 Oct 2013 at 2:58

[GoogleCodeExporter]

I'm not sure the patch in comment #3 addresses the issue in this bug (at least 
this didn't work on my freshly updated Ubuntu 13.10 64-bit intel system (w/GCC 
version 4.8.1).

Comment #1 referring to the inferno mailing list thread does.

In short (and this is my interpretation of much smarter people's analysis), 
this seems to be an issue with the behaviour of recent versions of GCC where 
the intention to not trap on divide by zero occurs.

The step that breaks is when limbo is run to generate a header file from the 
file module/math.m, specifically when the limbo tries to generate a constant 
from:
   NaN:        con 0./0.;

Charles mentions in the referred thread that he has a long-term fix in mind but 
sqweek provide a patch that seems to work for me. I've pasted it here to keep 
with the context of this report:

(thanks sqweek!)

Changing the asm codeblock in Linux/386/include/fpuctl.h:/^setfsr() to volatile 
and adding an "=a" output constraint fixes the immediate build problem. The 
diff looks like:

--- a/Linux/386/include/fpuctl.h    Sat Jun 08 13:03:33 2013 +0000
+++ b/Linux/386/include/fpuctl.h    Sun Jun 30 02:16:23 2013 +0800
<at> <at> -6,12 +6,12 <at> <at>
 static void
 setfcr(ulong fcr)
 {
-   __asm__(    "xorb   $0x3f, %%al\n\t"
+   __asm__ volatile(   "xorb   $0x3f, %%al\n\t"
    "pushw  %%ax\n\t"
    "fwait\n\t"
    "fldcw  (%%esp)\n\t"
    "popw   %%ax\n\t"
-   : /* no output */
+   : "=a" (fcr)
    : "al" (fcr)
    );
 }

Original comment by joseph.s...@gmail.com on 24 Oct 2013 at 6:10