Building GCC Failed: stubs-32.h missing

Building GCC Failed: stubs-32.h missing

[ronf]

I want to build gcc from source on my CentOS 6 x86-64 Linux system, but I am 
having a serious problem with the "configure" scripts and make files. The 
build process insists on accessing "stubs-32.h" even though my Linux system 
lacks this header file. My system has stubs.h and stubs-64.h header files in 
the /usr/include/gnu directory. The content of stubs.h is shown here: 

  /* This file selects the right generated file of `__stub_FUNCTION' macros
     based on the architecture being compiled for.  */

  #include <bits/wordsize.h>

  #if __WORDSIZE == 32
  # include <gnu/stubs-32.h>
  #elif __WORDSIZE == 64
  # include <gnu/stubs-64.h>
  #else
  # error "unexpected value for __WORDSIZE macro"
  #endif


The gcc source was obtained from ftp.gnu.org in the file gcc-4.8.2.tar.gz 
along with source for the GMP 4.3.2, ISL 4.11.1, MPFR 2.4.2, MPC 0.8.1 and 
CLooG 0.18.0 libraries. The GMP, ISL, MPFR, MPC and CLooG libraries build 
easily using their "configure" scripts and make files. For the gcc build, I 
let the configure script and make files for gcc also build the GMP, MPFR 
and MPC libraries since the gcc build can do this. 

In order to avoid the problem with the missing stubs-32.h file, I set the 
environment variables with 

  export CFLAGS=-D__WORDSIZE=64
  export CPPFLAGS=-D__WORDSIZE=64
  export CXXFLAGS=-D__WORDSIZE=64

and used the 

  --with-cpu-64=x86-64 --with-arch-64=x86-64 --with-tune-64=x86-64 and 
  --disable-isl-version-check 

options with the configure script. Despite all this, the build insisted on 
having the stubs-32.h file. I tried copying the stubs-64.h to stubs-32.h 
but this failed because the libraries coresponding to stubs-32.h were not 
made. 

I decided to build a new version of my glibc libraries that would have the 
stubs-32.h file. I downloaded glibc-2.12.2.tar.gz to compile it. However, 
the build of this glibc noted that I had a x86-64 GNU/Linux system and, 
thus, made the stubs-64.h file but omitted building the stubs-32.h file. 

CentOS has a GUI that helps manage software packages. I try to use this GUI, 
rather than using yum or rpm directly, because I believe I may run into 
trouble by mixing package managers. Thus, I tried to have the GUI install a 
glibc-devel package with stubs-32, but the GUI refused because I have a 
64-bit CentOS system. 

The versions of gcc packaged with CentOS 6 have internal errors when trying 
to compile some software packages such as the Healpy software. Since the 
CentOS GUI refuses to upgrade gcc to versions that don't fail, I wanted to 
have an auxilliary installation of gcc that would compile software without 
the internal errors. Compiling from source seems to be the safest way since 
the control provided by source prevents interference with my system 
installation. Since I want to avoid fouling my system, I frequently install 
software in private directories rather than system directories. 

Surely gcc is supposed to build itself. How can I get gcc to build? 




--
View this message in context: http://gcc.1065356.n5.nabble.com/Building-GCC-Failed-stubs-32-h-missing-tp1010178.html
Sent from the gcc - Help mailing list archive at Nabble.com.

Re: Building GCC Failed: stubs-32.h missing

[Marc Glisse]

On Mon, 10 Feb 2014, ronf wrote:

> I want to build gcc from source on my CentOS 6 x86-64 Linux system, but I am
> having a serious problem with the "configure" scripts and make files. The
> build process insists on accessing "stubs-32.h" even though my Linux system
> lacks this header file. My system has stubs.h and stubs-64.h header files in
> the /usr/include/gnu directory. The content of stubs.h is shown here:

Surely Google is your friend? Gcc-4.9 will print this message:

I suspect your system does not have 32-bit developement libraries (libc 
and headers). If you have them, rerun configure with --enable-multilib. If 
you do not have them, and want to build a 64-bit-only compiler, rerun 
configure with --disable-multilib.


-- 
Marc Glisse

Re: Building GCC Failed: stubs-32.h missing

[Kai Ruottu]

10.2.2014 23:38, Marc Glisse kirjoitti:
> On Mon, 10 Feb 2014, ronf wrote:
>
>> I want to build gcc from source on my CentOS 6 x86-64 Linux system, 
>> but I am
>> having a serious problem with the "configure" scripts and make files. 
>> The
>> build process insists on accessing "stubs-32.h" even though my Linux 
>> system
>> lacks this header file. My system has stubs.h and stubs-64.h header 
>> files in
>> the /usr/include/gnu directory. The content of stubs.h is shown here:
>
> Surely Google is your friend? Gcc-4.9 will print this message:
>
> I suspect your system does not have 32-bit developement libraries 
> (libc and headers). If you have them, rerun configure with 
> --enable-multilib. If you do not have them, and want to build a 
> 64-bit-only compiler, rerun configure with --disable-multilib.
>
>

But CentOS 6 surely has those development libraries!  Probably they 
aren't installed
as default but then many other packages aren't either.  Usually when one 
needs something,
in this case the capability to produce apps for the 32-bit Linux/x86, 
then one installs it!
I would assume searching for 'glibc-devel' in the package manager would 
show what is
missing.  Another way is to spy via the package names. In this case 
finding for instance :

ftp://ftp.funet.fi/pub/linux/mirrors/centos/6.5/os/x86_64/Packages/glibc-devel-2.12-1.132.el6.i686.rpm

wasn't any rocket science at all...

If one hasn't any need to produce also 32-bit apps then making a 
"stripped" toolchain
which doesn't have any 32-bit support, via the --disable-multilib', is 
the way to go. Then
the 32-bit libgcc, libstdc++ etc will not be produced during the GCC build.

Re: Building GCC Failed: stubs-32.h missing

[Jonathan Wakely]

On 10 February 2014 13:04, ronf wrote:
> Surely gcc is supposed to build itself. How can I get gcc to build?

http://gcc.gnu.org/wiki/FAQ#gnu_stubs-32.h

Re: Building GCC Failed: stubs-32.h missing

[Soufien Hidouri]

HI,

I had the same problem with fedora heisunbug and i solved it by
installing the glibc-devel.i686 package with the following commande :

yum install glibc-devel.i686

I guess your problem certainly will be solved by this command ;)



2014-02-11 1:46 GMT+01:00 Jonathan Wakely <jwakely.gcc@gmail.com>:
> On 10 February 2014 13:04, ronf wrote:
>> Surely gcc is supposed to build itself. How can I get gcc to build?
>
> http://gcc.gnu.org/wiki/FAQ#gnu_stubs-32.h

Re: Building GCC Failed: stubs-32.h missing

[ronf]

Thank you all for your helpful comments. I made the mistake of using several
configure options that were not needed. Using the "--disable-multilib"
option and omitting the unneeded options fixed the problem. Also, I found
that the GUI used on CentOS for managing packages had options for using or
omitting filters, and omitting the "only native packages" filter allowed the
GUI to download and install glibc-devel-2.12-1.182.elf6 (i686) package with
stubs-32.h in it. Thus I now have two ways to build GCC (one with and one
without stubs-32.h). 

I was surprised that the procedure for building the glibc packages (from
source) relied so heavily on glibc packages that were already installed. One
great feature of a compiler collection like GCC is the ability of compilers
to compile themselves from source. I was surprised that the build process
was so dependent on kernel libraries. I can understand gcc using kernel
libraries for its own internal operations, but I don't believe the build of
a GCC source package should be including kernel source (headers) from
outside the package or needing to link the compiled object code with kernel
libraries other than those generated by part of the build. If I try to
cross-compile GCC for another kernel, would I need compiled kernel libraries
for the target kernel? I hope I would only need the source code for the
target's libraries. Likewise use of GCC to build GCC for and on a native
machine should not need to access code outside the GCC source package except
for internal operations of the compilers that are performing the build. Do
you agree? 




--
View this message in context: http://gcc.1065356.n5.nabble.com/Building-GCC-Failed-stubs-32-h-missing-tp1010178p1011013.html
Sent from the gcc - Help mailing list archive at Nabble.com.

Re: Building GCC Failed: stubs-32.h missing

[Jonathan Wakely]

On 13 February 2014 15:34, ronf wrote:
> I was surprised that the procedure for building the glibc packages (from
> source) relied so heavily on glibc packages that were already installed. One
> great feature of a compiler collection like GCC is the ability of compilers
> to compile themselves from source. I was surprised that the build process
> was so dependent on kernel libraries.

The file you were missing is not a kernel header.

Re: Building GCC Failed: stubs-32.h missing

[Andrew Haley]

On 02/13/2014 11:34 PM, ronf wrote:
> I was surprised that the procedure for building the glibc packages (from
> source) relied so heavily on glibc packages that were already installed. One
> great feature of a compiler collection like GCC is the ability of compilers
> to compile themselves from source. I was surprised that the build process
> was so dependent on kernel libraries. I can understand gcc using kernel
> libraries for its own internal operations, but I don't believe the build of
> a GCC source package should be including kernel source (headers) from
> outside the package or needing to link the compiled object code with kernel
> libraries other than those generated by part of the build.

What kernel libraries are you talking about?  Please be specific.

Andrew.

Re: Building GCC Failed: stubs-32.h missing

[ronf]

Andrew Haley wrote
> On 02/13/2014 11:34 PM, ronf wrote:
>> I was surprised that the procedure for building the glibc packages (from
>> source) relied so heavily on glibc packages that were already installed.
>> One
>> great feature of a compiler collection like GCC is the ability of
>> compilers
>> to compile themselves from source. I was surprised that the build process
>> was so dependent on kernel libraries. I can understand gcc using kernel
>> libraries for its own internal operations, but I don't believe the build
>> of
>> a GCC source package should be including kernel source (headers) from
>> outside the package or needing to link the compiled object code with
>> kernel
>> libraries other than those generated by part of the build.
> 
> What kernel libraries are you talking about?  Please be specific.
> 
> Andrew.

I am sorry I didn't check my messages for so long. Since GCC now builds
easily, I don't see the errror messages naming the libraries and, thus, I
don't know what libraries were missing. However, I do remember the procedure
I used. 

First, since stubs-32.h was missing I copied stubs-64.h to stubs-32.h in an
attempt to trick the build into continuing. (This was a mistake since it was
unnecessary and wrong.) 

Second, I configured using the --enable-multilib option (another mistake). 

Third, I entered "make" and got error messages regarding missing libraries. 

I hope you will tell me there were no missing kernel libraries but just
confusion caused by my unusual bad procedure. I hope GCC really does compile
itself from source code without needing binary libraries other than
libraries used only for the internal operations of the compiler used to
build GCC. 




--
View this message in context: http://gcc.1065356.n5.nabble.com/Building-GCC-Failed-stubs-32-h-missing-tp1010178p1013143.html
Sent from the gcc - Help mailing list archive at Nabble.com.

Re: Building GCC Failed: stubs-32.h missing

[Andrew Haley]

On 02/20/2014 08:39 PM, ronf wrote:
> Andrew Haley wrote
>> On 02/13/2014 11:34 PM, ronf wrote:
>>> I was surprised that the procedure for building the glibc packages (from
>>> source) relied so heavily on glibc packages that were already installed.
>>> One
>>> great feature of a compiler collection like GCC is the ability of
>>> compilers
>>> to compile themselves from source. I was surprised that the build process
>>> was so dependent on kernel libraries. I can understand gcc using kernel
>>> libraries for its own internal operations, but I don't believe the build
>>> of
>>> a GCC source package should be including kernel source (headers) from
>>> outside the package or needing to link the compiled object code with
>>> kernel
>>> libraries other than those generated by part of the build.
>>
>> What kernel libraries are you talking about?  Please be specific.
> 
> I am sorry I didn't check my messages for so long. Since GCC now builds
> easily, I don't see the errror messages naming the libraries and, thus, I
> don't know what libraries were missing. However, I do remember the procedure
> I used. 
> 
> First, since stubs-32.h was missing I copied stubs-64.h to stubs-32.h in an
> attempt to trick the build into continuing. (This was a mistake since it was
> unnecessary and wrong.) 
> 
> Second, I configured using the --enable-multilib option (another mistake). 
> 
> Third, I entered "make" and got error messages regarding missing libraries. 
> 
> I hope you will tell me there were no missing kernel libraries but just
> confusion caused by my unusual bad procedure. I hope GCC really does compile
> itself from source code without needing binary libraries other than
> libraries used only for the internal operations of the compiler used to
> build GCC.

It really does.  Of course, it needs a C library.

Andrew.