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.
