ubuntu fedora - Error “gnu/stubs-32.h:No such file or directory” while compiling Nachos source code
include yum (9)
From the GNU UPC website:
Compiler build fails with fatal error: gnu/stubs-32.h: No such file or directory
This error message shows up on the 64 bit systems where GCC/UPC multilib feature is enabled, and it indicates that 32 bit version of libc is not installed. There are two ways to correct this problem:
- Install 32 bit version of glibc (e.g. glibc-devel.i686 on Fedora, CentOS, ..)
- Disable 'multilib' build by supplying "--disable-multilib" switch on the compiler configuration command
I am trying to install Nachos on my laptop and I have Ubuntu 11.04 on the laptop.
The code is in C and so to build it I assume I will need cross compiler. This is where my problem is. I downloaded the source code of the MIPS cross compiler using the command
and I unzipped it using
tar zxvf mips-decstation.linux-xgcc.gz
This is okay, but when I try to build the source code of the nachos os, using make, I get this error -
/usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory compilation terminated. make: *** [bitmap.o] Error 1
I am trying to follow the instructions given over here - http://mll.csie.ntu.edu.tw/course/os_f08/217.htm and everything is working fine except when I try to use make.
Try doing a
sudo apt-get install libc6-dev.
apt-file tells me that the file in question belongs to that package.
I was getting following error on a fedora 18 box:
1. /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory compilation terminated.
I Installed glibc.i686 and glibc-devel.i686, then compilation failed with following error:
2. /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-redhat-linux/4.7.2/libgcc_s.so when searching for -lgcc_s /usr/bin/ld: cannot find -lgcc_s collect2: error: ld returned 1 exit status
I installed (yum install) glibc.i686 glibc-devel.i386 and libgcc.i686 to get rid of the compilation issue.
Now compilation for 32 bit (-m32) works fine.
FWIW, it smells like an error (or at least a potential source of future pain) to be using files from /usr/include when cross-compiling.
# sudo apt-get install g++-multilib
Should fix this error on 64-bit machines (Debian/Ubuntu).
If you are facing this issue in Mac-OSX terminal with python, try updating the versions of the packages you are using. So, go to your files in python and where you specified the packages, update them to the latest versions available on the internet.
Hmm well I am on ubuntu 12.04 and I got this same error when trying to compile gcc 4.7.2
I tried installing the
libc6-dev-i386 package and got the following:
Package libc6-dev-i386 is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source E: Package 'libc6-dev-i386' has no installation candidate
I also set the correct environment variables in bash:
export LIBRARY_PATH=/usr/lib/$(gcc -print-multiarch) export C_INCLUDE_PATH=/usr/include/$(gcc -print-multiarch) export CPLUS_INCLUDE_PATH=/usr/include/$(gcc -print-multiarch)
however, I was still getting the error then I simply copied
stubs-32.h over to where gcc was expecting to find it after doing a quick diff:
[email protected]:/usr/include/i386-linux-gnu/gnu$ diff ../../gnu ./ Only in ./: stubs-32.h Only in ../../gnu: stubs-64.h [email protected]:/usr/include/i386-linux-gnu/gnu$ sudo cp stubs-32.h ../../gnu/ [sudo] password for vic: [email protected]:/usr/include/i386-linux-gnu/gnu$ diff ../../gnu ./ Only in ../../gnu: stubs-64.h [email protected]:/usr/include/i386-linux-gnu/gnu$
It's compiling now, let's see if it complains more ...
gnu/stubs-32.h is not directed included in programms. It's a back-end type header file of
gnu/stubs.h, just like
gnu/stubs-64.h. You can install the
multilib package to add both.
This is really a compiler (in fact it embbeds 2 compilers) and it makes totally self sufficient executables. You don't need any supplementary library or any kind of runtime to execute it on your server. You just have to have it compiled for your target computer architecture.
From the documentation :
There are two official Go compiler tool chains. This document focuses on the gc Go compiler and tools (6g, 8g etc.). For information on how to work on gccgo, a more traditional compiler using the GCC back end, see Setting up and using gccgo.
The Go compilers support three instruction sets. There are important differences in the quality of the compilers for the different architectures.
amd64 (a.k.a. x86-64); 6g,6l,6c,6a A mature implementation. The compiler has an effective optimizer (registerizer) and generates good code (although gccgo can do noticeably better sometimes).
386 (a.k.a. x86 or x86-32); 8g,8l,8c,8a Comparable to the amd64 port.
arm (a.k.a. ARM); 5g,5l,5c,5a Supports only Linux binaries. Less widely used than the other ports and therefore not as thoroughly tested.
Except for things like low-level operating system interface code, the run-time support is the same in all ports and includes a mark-and-sweep garbage collector, efficient array and string slicing, and support for efficient goroutines, such as stacks that grow and shrink on demand.
The compilers can target the FreeBSD, Linux, NetBSD, OpenBSD, OS X (Darwin), and Windows operating systems. The full set of supported combinations is listed in the discussion of environment variables below.
On a server you'll usually target the
Note that Go is well known for the speed of compilation. When deploying my server programs, I don't build for the different platforms on the development computer : I deploy the sources and I compile directly on the production servers. Since Go1 I never had a code compiling on one platform and not compiling on the other ones.
On Windows I had no problem in making an
exe on my development computer and simply sending this
exe to people never having installed anything Go related.