I have a system that I do not have root access to, but I need to install the current version of GCC (4.7.2) on.
The system is running an x86_64 build of Linux 2.6.18 and already has GCC 4.1 (without C++ support even though --version says it was built with it).
EDIT 5: At this point, the steps below are just one set of things that I've tried. I've started clean a few times since then. I'm looking for someone to detail the exact order I need to make everything in with all of the switches required.
This is the process I've gone through so far (where ROOT is a folder in my home directory)
make-3.82>./configure --prefix=$ROOT && make && make install && hash -r
binutils-2.23>./configure --prefix=$ROOT && make && make install
autoconf-2.69>./configure --prefix=$ROOT && make && make install
automake-1.9>./configure --prefix=$ROOT && make && make install
flex-2.5.37>./configure --prefix=$ROOT && make && make install
libunwind-1.1>./configure --prefix=$ROOT && make && make install
gcc-4.7.2-scratch>../gcc-4.7.2/configure --prefix=$ROOT \
--disable-multilib --disable-nls --enable-languages=c,c++ \
&& make && make install && hash -r
ncurses-5.9>./configure --prefix=$ROOT && make && make install
texinfo-4.13>./configure --prefix=$ROOT && make && make install
glibc-2.14-scratch>touch $ROOT/etc/ld.so.conf
Patched glibc with patch from http://sourceforge.net/apps/trac/unattended/wiki/ModifyingTheBootDisk#PatchGLibc (correcting line numbers for 2.14)
glibc-2.14-scratch>../glibc-2.14/configure --prefix=$ROOT \
--with-headers=$3_3_4_HEADERS && make && make install
The flags I added were to get rid of undefined reference to '__isoc99_sscanf'
. I don't know what combination of flags was actually necessary to fix that, but it fixed the problem with these flags.
gcc-4.7.2-scratch2>../gcc-4.7.2/configure --prefix=$ROOT \
--disable-multilib --disable-nls --enable-languages=c,c++ \
CPPFLAGS="-I$ROOT/include" CFLAGS="-g -O2 -lc" \
CXXFLAGS="-g -O2 -lc" LDFLAGS="-L$ROOT/lib \
-L$ROOT/lib64" && make && make install
Now I get this error during the GCC build:
build/genmddeps ../../gcc-4.7.2/gcc/config/i386/i386.md > tmp-mddeps
build/genmddeps: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by build/genmddeps)
The error makes sense because the libc in /lib64 is version 2.5, but I don't know how to get GCC to use the one that I built that installed to $ROOT/lib.
EDIT 1: Adding -rpath didn't help, but I added my lib directories to LD_RUN_PATH and LD_LIBRARY_PATH. With these set I couldn't run anything because I was getting the error [program_name]: error while loading shared libraries: /home/mrambiguous/root/lib/libc.so.6: ELF file OS ABI invalid
Another strange thing to note is that when I tried the -rpath suggestion, I started getting errors from GCC about unrecognized command line options (such as -V). I had to set it to use the system's GCC 4.1. Now I'm not sure if my first build of GCC became corrupted somehow or if it was ever being used in the first place.
EDIT 2: I just opened libc.so.6 in vim to see if I could find anything about the ABI in plain text and it is in there with the copyright info. libc ABIs: UNIQUE IFUNC
It also confirms that GCC 4.7.2 was working in that same block of text. Compiled by GNU CC version 4.7.2
EDIT 3: Removed $ROOT, reinstalled everything, same issue of not recognizing -V and -qversion as valid options.
EDIT 4: I tried editing the ELF header by using brandelf -t SVR4 libc.so.6
, but that just gives me a new error unexpected PLT reloc type 0x25
I am in a hurry so I can't analyze your error messages in detail.
Newer glibc and old glibc are not only ABI incompatible, but also headers, see gcc bug 52922.
Therefore any mixing will result in errors like you encountered, you need to be extremely careful.
Hand tuning is hopelessly tedious.
If your goal is to use gcc-4.7.2, I recommend you to Gentoo Prefix. I have many instances of Gentoo Prefix running on RHEL 5 (which have 2.6.18 kernel, gcc-4.1 and glibc-2.5 as you do). This compiles gcc-4.7.2 on top of glibc-2.5.
If your want some fun of using newer glibc, take a look at Prefix/libc. It is a work-in-progress though. Expect many breakage. But it won't be a big draw back as you are trying to compile out a modern toolchain by hand, will it?
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With