I downloaded and built gcc 4.8.1 on my desktop, running 64-bit Ubuntu 12.04. I built it out of source, like the docs recommend, and with the commands
../../gcc-4.8.1/configure --prefix=$HOME --program-suffix=-4.8
make
make -k check
make install
It seemed to pass all the tests, and I installed everything into my home directory w/ the suffix -4.8 to distinguish from the system gcc, which is version 4.6.3.
Unfortunately when I compile c++ programs using g++-4.8 it links to the system libc and libstdc++ rather than the newer ones compiled from gcc-4.8.1. I downloaded and built gcc 4.8 because I wanted to play around with the new C++11 features in the standard library, so this behaviour is definitely not what I wanted. What can I do to get gcc-4.8 to automatically link to the standard libraries that came with it rather than the system standard libraries?
I just had the same problem when building gcc-4.8.2. I don't have root access on that machine and therefore need to install to my home directory. It took several attempts before I figured out the magic required to get this to work so I will reproduce it here so other people will have an easier time. These are the commands that I used to configure gcc:
That got me a working binary but any program I built with that version of g++ wouldn't run correctly unless I built it with the -Wl,-rpath,$prefix/lib64 option. It is possible to get g++ to automatically add that option by providing a specs file. If you run
you can see which directories it checks for a specs file. In my case it was $prefix/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/specs so I ran g++ -dumpspecs to create a new specs file:
and then edited that file to provide the -rpath option. Search for the lines like this:
and edit to add the rpath option:
The %M expands to either ../lib or ../lib64 depending on whether you are building a 32-bit or a 64-bit executable.
Note that when I tried this same trick on an older gcc-4.7 build it didn't work because it didn't expand the %M. For older versions you can remove the %M and just hardcode lib or lib64 but that is only a viable solution if you only ever build 32-bit executables (with lib) or only ever build 64-bit executables (with lib64).
gcc -print-search-dirs
will tell you where your compiler is looking for runtime libraries, etc. You can override this with the-B<prefix>
option.When you link with your own gcc you need to add an extra run-time linker search path(s) with
-Wl,-rpath,$(PREFIX)/lib64
so that at run-time it finds the shared libraries corresponding to your gcc.I normally create a wrapper named
gcc
andg++
in the same directory asgcc-4.8
andg++-4.8
which I invoke instead ofgcc-4.8
andg++-4.8
, as prescribed in Dynamic linker is unable to find GCC libraries:When installing
SUFFIX
andPREFIX
should be replaced with what was passed toconfigure
:(
gcc-wrapper.sh
is that bash snippet).The above solution does not work with some versions of
libtool
becauseg++ -Wl,... -v
assumes linking mode and fails with an error.A better solution is to use specs file. Once gcc/g++ is built, invoke the following command to make gcc/g++ add
-rpath
to the linker command line (replace${PREFIX}/lib64
as necessary):