4

I work on a computing cluster running CentOS6/RHEL6 that I share with ~100 other users, overseen by a single IT admin.

Recently, I started writing in C++, and some of my code depends on C++11. According to this webpage, C++11 is supported by gcc versions 4.8.1 and above.

Unfortunately, the computing cluster has version 4.4.7.

A little while ago, for a different reason, I tried to install gcc version 4.8.4 to a location under my home directory on the cluster. The installation failed, with this error message. Some Googling led me to believe I should update glibc, so I attempted to install a newer version of that to my home directory. That failed dramatically.

My IT admin concluded, "It probably won't work to modify the version of gcc on the cluster." Before I annoy her with more questions (because at this point I need an updated version of some C compiler), I'm crowd-sourcing these:

(1) Is installing gcc version 4.8.1+ to my user account feasible? (After I tried to do this last time, some people said it was fundamentally a terrible idea.)

(2) If the answer to (1) is yes, what precautions should I take this time to make sure the installation is successful? Is installing glibc to my account necessary? Is that feasible?

(3) If the answer to (1) is no, would it be feasible for my IT admin to install a newer version of gcc system-wide, without disrupting code that depends on the version already present?

(4) If none of the above is feasible for gcc, does the situation change with another C compiler?

To summarize, I'm looking for someone with knowledge of gcc (or another C compiler) to explain how a person (without sudo authority) would go about upgrading it, if that's possible.

Community
  • 1
abcd
  • 143

2 Answers2

2

I was able to build GCC 4.8.5 from source in a home directory on Centos 6.7. I'm using the distro glibc; I didn't have to build glibc.

Caveat: I'm doing this on a system where the build dependencies for the distro's GCC 4.4.x source package are installed as well as the libmpc-devel package from the epel repository. If those are missing you may have to build them from source into a home directory first and change the gcc build process in some way to use them from there (if that's even possible.)

Building GCC:

  1. Grab GCC source

    curl -LO https://mirrors.kernel.org/gnu/gcc/gcc-4.8.5/gcc-4.8.5.tar.bz2

  2. Extract

    tar xf gcc-4.8.5.tar.bz2

  3. Make a build directory outside of the GCC source directory and go to it

     mkdir build && cd build

  4. Configure. I did:

     ../gcc-4.8.4/configure --build=x86_64-linux-gnu --prefix=/home/rakslice/gcc_4_8 \
                        --enable-checking=release --enable-languages=c,c++,fortran \
                        --disable-multilib --program-suffix=-4.8

  5. Build. I have 4 cores so I did:

     make -j 5

  6. Install

     make install

  7. Now I can compile and run some test code.

     /home/rakslice/gcc_4_8/bin/g++-4.8     hello.cpp   -o hello
 ./hello
 Hello, World!
rakslice
  • 2,846
0

Regarding your specific questions:

(1) Yes it is feasible, but it may not be fun.

(2) No, usually you can use the system glibc. From gcc you need libstdc++, libgcc etc.

My approach would be to follow the official instructions very closely and only resort to an unofficial instruction if it matches your platform very well.

I would actually not bother with 4.8 and go straight to one of the current release series (5.2 or 4.9).

Note: I have not done non-root gcc installation myself, but I work on systems that maintain different versions of gcc as gnu modules.

Zulan
  • 249
  • 1
  • 10