Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am trying to get a modern GCC to compile on Centos 6.4. The problem is that Centos does not have a modern glibc and GCC 4.8.x and 4.7.x keep giving me the following compile error:

... -DL_gcov -c ../../.././libgcc/libgcov.c
In file included from /usr/include/features.h:385:0,
                 from /usr/include/stdio.h:28,
                 from ../../.././libgcc/../gcc/tsystem.h:88,
                 from ../../.././libgcc/libgcov.c:29:
/usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory

The problem here is the gnu/stubs-32.h is part of the modern glibc and Centos 6.4 doesn't seem to have it. I've tried building my own glibc but as soon as it gets installed and in my local LD_LIBRARY_PATH I can't run any other programs, because all of the existing executables on the system try to link against it and they fail.

I want to use the new compiler because it has dramatically better handling of C++ STL code, and because the optimizer in GCC 4.8 makes my code run in 1/2 the time as the GCC 4.4.7 compiler that comes with Centos.

Any suggestions on how to do this?

share|improve this question
Do you really, absolutely, need the newer compiler?! – Michael Hampton Jul 16 '13 at 18:27
My code runs in 1/2 the time with the better compiler. The code is running on a supercomputer and takes 3-7 days to run. Without the better compiler, it takes 6-14 days to run. – vy32 Jul 16 '13 at 21:53
In that case, do you really, absolutely, need the older OS distribution? – Michael Hampton Jul 16 '13 at 22:30
We are not able to upgrade the system. – vy32 Jul 17 '13 at 0:50
It sounds like you might not have much of a choice. – Michael Hampton Jul 17 '13 at 0:54
up vote 2 down vote accepted

Build the gcc compiler on your Centos and target only 64 bits.
Excerpt from documentation:

C standard library and headers In order to build GCC, the C standard library and headers must be present for all target variants for which target libraries will be built (and not only the variant of the host C++ compiler). This affects the popular ‘x86_64-unknown-linux-gnu’ platform (among other multilib targets), for which 64-bit (‘x86_64’) and 32-bit (‘i386’) libc headers are usually packaged separately. If you do a build of a native compiler on ‘x86_64-unknown-linux-gnu’, make sure you either have the 32-bit libc developer package properly installed (the exact name of the package depends on your distro) or you must build GCC as a 64-bit only compiler by configuring with the option --disable-multilib. Otherwise, you may encounter an error such as ‘fatal error: gnu/stubs-32.h: No such file’

share|improve this answer

Ahh, welcome to the fun of super outdated libraries. I've run into similar problems, and our solution was to compile a second version of GLIBC and explicitly use that when starting software.

I've only had to do this on CentOS 5, so you may be able to get away with higher software versions then I mention.

You'll need to build GLIBC like this:

CFLAGS='-march=i686 -O2' ../configure --prefix=/home/glibc215 \
  make -j 4 && make install

(I was using GLIBC 2.15, similar commands should work with newer versions)

Once it's built, manually run your app with something like this:

/home/glibc215/lib/ --library-path /home/glibc215/lib/:. /bin/bash

Things are going to be further complicated by the fact you need a modern version of GCC. I don't have a decent solution for you, you're going to need to play around with running things with the alternate version of glibc in order to get your newer gcc to build properly.

share|improve this answer
Thanks. I believe this will work. However, I found another solution, and that is to do the compiles on another system and distribute the binaries and shared libraries to this system. That's also ugly, but I think that it works too. – vy32 Jul 17 '13 at 11:08

You could install a newer glibc into ~/lib and install gcc in ~/bin and linking against the newer glibc. I'd advise to use that only for your application that runs on the supercomputer and to link everything (including libc) statically to avoid making a bigger mess than you'll have to make for this.

It's not a particularly neat/elegant solution, but it may just get the job done. I did something similar years ago when mucking about with and not wanting to mess up the entire system :-)

share|improve this answer
Actually, I tried this and it didn't work. As soon as the shared libraries were installed in the directory, all existing binaries stopped working. Many of the tools require the new libraries to build. – vy32 Jul 17 '13 at 0:50

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.