Inferno fails to build with gcc 4.8.1 on Linux amd64

[GoogleCodeExporter]

What steps will reproduce the problem?
Build inferno on Linux amd64 (386 target) with gcc version 4.8.1 (or .2)

What is the expected output? What do you see instead?
- I expect to not get floating point exceptions from limbo and errors about 
structures not containing elements within keyring.c

Which operating system are you using?
- Gentoo Linux amd64

Please provide any additional information below.
 Switching back to gcc 4.7.3 fixes the issue completely. This is meant to be a warning more than any specific issue.

Original issue reported on code.google.com by Theoreti...@gmail.com on 30 Aug 2014 at 4:34

[GoogleCodeExporter]

Can you provide a copy of the output? Thanks.

Original comment by Charles....@gmail.com on 30 Aug 2014 at 9:48

[GoogleCodeExporter]

I'm using 4.8.2 on ubuntu amd64,and it seemed fine, but perhaps something has 
changed. I'll try again.

Original comment by Charles....@gmail.com on 30 Aug 2014 at 9:50

[GoogleCodeExporter]

Interesting that you have no issues, I had to export NPROC=1 since normally it 
is 24 and totally makes the output unreadable. So the only file I get an issue 
with (after applying the temporary fix described in issue 300) is crypt.c but I 
have attached the log output. I apologize for it being so long but I wasn't 
sure what was important or not. 

I was wrong, I'm running gcc 4.8.3, here is the -v output for gcc:

jwscoggins@tycho ~$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.3/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.3/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-4.8.3/work/gcc-4.8.3/configure 
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr 
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.3 
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/include 
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.3 
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.3/man 
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.3/info 
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/include/g++-v4 
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.8.3/python 
--enable-languages=c,c++,objc,fortran --enable-obsolete --enable-secureplt 
--disable-werror --with-system-zlib --enable-nls --without-included-gettext 
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/ 
--with-pkgversion='Gentoo 4.8.3 p1.1, pie-0.5.9' --enable-libstdcxx-time 
--enable-shared --enable-threads=posix --enable-__cxa_atexit 
--enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 
--disable-altivec --disable-fixed-point --enable-targets=all --disable-libgcj 
--enable-libgomp --disable-libmudflap --disable-libssp --enable-lto 
--without-cloog
Thread model: posix
gcc version 4.8.3 (Gentoo 4.8.3 p1.1, pie-0.5.9) 

Original comment by Theoreti...@gmail.com on 30 Aug 2014 at 3:30

Attachments:

• inferno-crashlog

[GoogleCodeExporter]

It looks as if runt.h or one of the other generated .h files in libinterp has 
been truncated or not generated properly, since they have those definitions.

Original comment by Charles....@gmail.com on 30 Aug 2014 at 4:02

[GoogleCodeExporter]

Is there a way to regenerate these files?

Original comment by Theoreti...@gmail.com on 30 Aug 2014 at 4:13

[GoogleCodeExporter]

Ah I see what happened, a bunch of the libinterp headers are marked as 
modified. I reverted them but now I get errors in keyring.c. 

Original comment by Theoreti...@gmail.com on 30 Aug 2014 at 5:16

Attachments:

• inferno_crashlog2

[GoogleCodeExporter]

I saw the same problem, running on a virtual machine under VirtualBox of a 
Mint/ubuntu 32bit i386 install.    

After I applied the patch from Inferno bug#300, and then did a "mk nuke", then 
the "mk install" build completed ok.    

Gcc is version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)

(BTW, the line in the bug#300 patch that literally reads:

<at> <at> -6,12 +6,12 <at> <at>

actually means (should be) :

@@ -6,12 +6,12 @@

for those who didn't recognize the mangled line.
)

Original comment by terryhei...@gmail.com on 1 Sep 2014 at 9:55