Trouble compiling modern GCC with antique glibc

Question

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?

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
Because it's a shared resource among hundreds of users and I'm not the administrator. — vy32, Jul 17 '13 at 11:07

score 3 · Answer 1 · answered Jul 17 '13 at 02:45

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/ld-linux.so.2 --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.

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

score 2 · Accepted Answer · answered Sep 23 '15 at 16:35

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’

score 0 · Answer 3 · answered Jul 16 '13 at 22:03

0

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 ld.so and not wanting to mess up the entire system :-)

answered Jul 16 '13 at 22:03

Dennis Kaarsemaker

18,793
2
43
69

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 00:50

Trouble compiling modern GCC with antique glibc

3 Answers3