31 July 2012

217. Recently...

Recently I've been busy preparing lectures (phew!), which means I've been kinder to my computer than is normal. Still, I managed to get myself into a few situations. The need to 'get stuff done' overrode the importance of documentation, but here's the low-down in case someone finds themselves in a similar situation:


1. Upgrades keep on getting stuck when restarting nfs/nfsd (nfs-common, nfs-kernel-server).
Normally I don't have any problems with nfs -- it's a tried and tested technology -- but one of my cluster nodes was giving me grief.

The key was to comment out everything in /etc/exports and commenting out nfs mounted partitions in /etc/fstab, then adding nfs and nfsd to /etc/modprobe.d/blacklist.conf (not sure this actually did anything), rebooting, throwing in

sudo rmmod nfs nfsd 


to be on the safe side, then doing

sudo dpkg --configure -a

to get dpkg/apt back in working order. After that I could uncomment everything in /etc/exports and /etc/fstab, and whitelist my drivers again.

Problem solved.

2. Nvidia is still a headache.
Since I was given a rare opportunity to reboot my front node I did a bit of work on it. Mainly, I wanted to allow gdm to start again, and figured I'd return to my nvidia driver managment to dkms-y goodness.

So I fired up smxi, selected 'debian-nvidia' and...everything was messed up. Long story short: I got it working with gdm3 by picking 'current driver' in smxi (always blacklist nouveau if you want to use/install nvidia drivers), making sure that there was no 'vga' (e.g.  vga=0x0318 ) in GRUB_CMDLINE_LINUX in /etc/default/grub and rebooting liberally.

I later got the debian-nvidia (dkms) version working by 1) not using frambuffer and 2) manually removing all nvidia legacy drivers that smxi pulled in. Well, that's working as in no error messages and the desktop looking fine.

3. GNOME 3 not diplaying all letters
e.g. 'guake' was rendered as 'g ak '. This happened on a low-powered system. A 'fix' was to go to advanced settings (gnome-tweak-tool), select font and change scaling from 1.0 to 1.2 and above.

It's not much of a 'fix', so I ended up nuking GNOME from that system and replacing it with KDE to have a reason to get more familiar with it. In the interest of balance I nuked all other DEs from another box and put LXDE on it. To paraphrase the Dos Equis commercial: I don't always use a DE, but when I do, I want to learn something new.

I've used KDE and GNOME on and off over the past 12 years, but you get rusty -- and both KDE and GNOME have changed enough from v 3.x and 2.x, respectively, that they aren't the same environment anymore. I still get an initial feeling of joy when I sit down by an NMR console and discover a red hat system with a 3.x desktop. Which is quickly followed by being annoyed over not having root access, but whatever. As for the usual gnome 2 vs gnome 3 arguments -- I like gnome3 in general. I just hate the idea of settings being hidden or disabled, and functionality being reduced. Enough so that I'm still looking for a potential replacement.

So far :
KDE -- I like it. It's overdoing the desktop effects a bit (out of the box) but, since it's KDE, it's easy to turn things on and off. I'm still a GNOME man, and KDE doesn't have the warm fuzzy feeling of home yet, but I can see how I could get used to it. I just need to get over my outdated idea that KDE is for windows users (I've never used a Mac so I guess I'm a reformed windows -- actually DOS -- user more than anything else).

KDE on one of my other systems seems to be messing up GNOME 3 though -- e.g. the mouse cursor theme gets transferred to gnome, and the pop-up notifications are those of kwin and not gnome-shell.  Not sure whether it's KDE causing it or whether I've messed a bit too much with my system.

LXDE -- it's functional and has long been my choice for virtual installations of linux for windows users. It's minimalistic in the sense that yes, it does provide a desktop, but no, it doesn't try to do anything beyond providing a set of menus and a bit of themeing. And that's a good thing. If you're going to impress a mate -- use gnome or kde. If you just need to get something done and launch a piece of software, lxde's your mate.

4. One of my systems lacked /etc/init.d/vboxdrv
Not all my collaborators use linux, so I keep a virtual copy of XP around for when I'm absolutely forced to use MS Word (OpenOffice sometimes changes the layout and it quickly becomes messy on collaborative documents). When taking a quick break to edit a manuscript in virtualbox I got the usual no driver present, 'run /etc/init.d/vboxdrv setup' message. Well, there was no /etc/init.d/vboxdrv in spite of dkms and vboxdrv-dkms being installed in addition to all the kernel headers. Turns out that the quickest way, assuming that locate vboxdrv doesn't come up empty (i.e. it's somewhere in the kernel tree) is just to mod it.
modprobe vboxdrv


To avoid it in the future, stick
vboxdrv
somewhere in your /etc/modules


5. Mysteriously self-rotating gnuplot images in latex 
Came down to a stupid mistake. I was doing:

set term postscript enhanced colour
set output 'acid.eps'
set border 3
set xtics nomirror
set ytics nomirror

I forgot to add eps -- getting rusty I suppose.

set term postscript enhanced eps colour
set output 'acid.eps'
set border 3
set xtics nomirror
set ytics nomirror

Surprised it hasn't happened before during all these years of latex usage.

6. Setting default line printer
me@beryllium:$ lpq
lpq: Error - no default destination available.



me@beryllium:$ lpstat -a
AdobePDF accepting requests since Mon 06 Aug 2012 08:01:32 EST
AdobePDF7 accepting requests since Mon 06 Aug 2012 08:01:32 EST
AdobePDF8 accepting requests since Mon 06 Aug 2012 10:04:13 EST
AdobePDF8@johnbowmansimac.dbs.monash.edu.au accepting requests since Mon 06 Aug 2012 08:01:32 EST
AdobePDF9 accepting requests since Mon 06 Aug 2012 08:01:32 EST
AdobePDF9@130.194.162.66 accepting requests since Mon 06 Aug 2012 08:01:32 EST
biol08r159p1 accepting requests since Mon 06 Aug 2012 08:01:32 EST
Canon_iP4300 accepting requests since Mon 06 Aug 2012 08:01:32 EST
Canon_MP460 accepting requests since Mon 06 Aug 2012 10:09:36 EST
Colour_109a accepting requests since Mon 06 Aug 2012 08:01:32 EST
global-mfp accepting requests since Mon 28 May 2012 14:27:30 EST
GlobalMFP@s0001203.dbs.monash.edu.au accepting requests since Mon 06 Aug 2012 08:01:32 EST
HP_LaserJet_Professional_P1102w accepting requests since Sat 04 Aug 2012 23:08:16 ESTHPColourLaserCP3505 accepting requests since Mon 06 Aug 2012 08:01:32 EST
HPLaserJetP3005 accepting requests since Mon 06 Aug 2012 08:01:32 EST

 me@beryllium:$ lpoptions -d HP_LaserJet_Professional_P1102w
auth-info-required=none copies=1 device-uri=hp:/usb/HP_LaserJet_Professional_P1102w?serial=000000000Q91K4WVSI1c finishings=3 job-hold-until=no-hold job-priority=50 job-sheets=none,none marker-change-time=0 number-up=1 printer-commands=AutoConfigure,Clean,PrintSelfTestPage printer-info='HPIJS -- drv:///hpijs.drv/hp-laserjet_professional_p1102w-hpijs.ppd' printer-is-accepting-jobs=true printer-is-shared=true printer-location printer-make-and-model='HP LaserJet Professional p1102w, hpcups 3.12.4, requires proprietary plugin' printer-state=5 printer-state-change-time=1344085696 printer-state-reasons=paused printer-type=8425484 printer-uri-supported=ipp://localhost:631/printers/HP_LaserJet_Professional_P1102w


7. The next Debian is codenamed Jessie!
I'm only 6 days late...apparently that's the cowgirl.

25 July 2012

216. Quantum Espresso on ROCKS 5.4.3 / CentOs 5.6 -- Almost got it.

Preamble:

I've seen just about any error message imaginable when compiling Quantum Espresso. You can most likely get around them by following this guide ad verbatim 
(no parallel environment detected, can't build fortran programs, no linker, parallel vs serial compiler etc.)

This compile is nothing like the easy-breezy one on debian, because of one reason: CentOS 5.6 is old. It's so old that the default gcc version can't compile QE. You'd encounter similar problems with an increasing number of software packages, including ABINIT.

      CentOS 5.6: gcc version 4.1.2 20080704 (Red Hat 4.1.2-50)
      Wheezy:       gcc version 4.7.1 (Debian 4.7.1-2)

The crusty compiler collection means we have to hammer out errors like these during compilation:


In file dfile_star.f90:28
    INTEGER,ALLOCATABLE ::  npert (:), irgq (:)
                      1
Error: Attribute at (1) is not allowed in a TYPE definition
 In file dfile_star.f90:37

    REAL(DP),ALLOCATABLE :: gi (:,:), gimq (:), eigen(:)
                       1
Error: Attribute at (1) is not allowed in a TYPE definition
 In file dfile_star.f90:42

    COMPLEX(DP),ALLOCATABLE :: u(:,:), t(:,:,:,:), tmq (:,:,:)
                          1
Error: Attribute at (1) is not allowed in a TYPE definition


Hence the requirement to first compile GCC 4.7, even if it takes a couple of hours. 

To the students out there swearing (and sweating) over their professors' insistence on using ROCKS/CentOS: compiling a compiler is not a wasted skill and just might be useful in building cross compilation environments for the time when you decide that science can take a hike and there's more money in working on setting up embedded systems. At least it'll buy you a little geek cred. 

Also, it seems that you need to use math and mpi libs compiled with the same compiler as you use to compile quantum espresso. So...lots of steps today as well!

Also, I haven't reported the configure bug for openmpi 1.6. Feel free to reproduce and report it.

I'm not happy that Quantum Espresso ignores the compile flags I've given it and defaults to things it should not default. I've had to jump through way too many hoops to be happy about this. OpenMPI not supporting program-suffix annoys me as well.

This is another massive compile...I'd rate it as my most annoying, troublesome and infuriating one yet.


1. Build GCC (gfortran, g++, gcc) 4.7 according to this post:
 http://verahill.blogspot.com.au/2012/07/compiling-gcc-471gfortran-471-on-centos.html
Make sure that
export PATH=$PATH:/share/apps/tools/gcc/gcc47/bin

2. Create target directory structure
sudo mkdir /share/apps/libs
sudo chown $USER /share/apps/lib

3. Recompile GNU OpenMP (libgomp)
It's probably easier you start with a freshly extracted gcc-4.7.1
cd ~/tmp/gcc
mkdir newgcc
cp gcc-4.7.1.tar.gz newgcc/
cd newgcc
tar xvf gcc-4.7.1
cd gcc-4.7.1/libgomp
mkdir build
cd build/
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/share/apps/tools/gcc/mpc/lib:/share/apps/tools/gcc/gmp/lib:/share/apps/tools/gcc/mpfr/lib
.././configure CC=gcc-gcc-4.7 CXX=g++-gcc-4.7 F77=gfortran-gcc-4.7 FC=gfortran-gcc-4.7 --prefix=/share/apps/tools/gcc/gcc47

md5sum /share/apps/tools/gcc/gcc47/lib/libgomp.so.1.0.0
23db68121aacf1e7d896704474e26350  /share/apps/tools/gcc/gcc47/lib/libgomp.so.1.0.0

make
make install

md5sum /share/apps/tools/gcc/gcc47/lib/libgomp.so.1.0.0
791a1ceb0ea4009e22703b82e8ce1ff4  /share/apps/tools/gcc/gcc47/lib/libgomp.so.1.0.0

4.  Compile OpenMPI using your new GCC 
cd ~/tmp/
wget http://www.open-mpi.org/software/ompi/v1.6/downloads/openmpi-1.6.tar.gz
tar xvf openmpi-1.6.tar.gz
cd openmpi-1.6
mkdir build
cd build/
export LD_LIBRARY_PATH=/share/apps/tools/gcc/gcc47/lib64:/share/apps/tools/gcc/gcc47/lib/gcc/x86_64-unknown-linux-gnu/4.7.1:/share/apps/tools/gcc/gmp/lib:/share/apps/tools/gcc/mpc/lib:/share/apps/tools/gcc/mpfr/lib

.././configure --prefix=/share/apps/libs/openmpi47 CC=gcc-gcc-4.7 FC=gfortran-gcc-4.7 F77=gfortran-gcc-4.7 F90=gfortran-gcc-4.7 CPP=cpp-gcc-4.7 CXX=g++-gcc-4.7 --with-sge LDFLAGS="-L/share/apps/tools/gcc/gcc47/lib64 -L/share/apps/tools/gcc/gcc47/lib/gcc/x86_64-unknown-linux-gnu/4.7.1 -L/share/apps/tools/gcc/gmp/lib -L/share/apps/tools/gcc/mpc/lib -L/share/apps/tools/gcc/mpfr/lib -L/share/apps/tools/gcc/gcc47/lib" CPPFLAGS="-I/share/apps/tools/gcc/mpc/include -I/share/apps/tools/gcc/gmp/include -I/share/apps/tools/gcc/mpfr/include -I/share/apps/tools/gcc/gcc47/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/include"

** There's a bug in the openmpi configure script leading to config failure due to to an extra space being introduced in front of -L when testing the F77 compiler. Exporting the LD_LIBRARY_PATH is done to get around that. **

make
make install

cd /share/apps/libs/openmpi47bin/
ls mpi* |xargs -I {} ln -s {} {}-gcc-4.7
echo 'export PATH=$PATH:/share/apps/libs/openmpi47/bin' >> ~/.bashrc
source ~/.bashrc

cd /share/apps/libs/openmpi47share/openmpi/
ln -s mpif77-vt-wrapper-data.txt mpif77-gcc-4.7-vt-wrapper-data.txt
ln -s mpif90-vt-wrapper-data.txt mpif90-gcc-4.7-vt-wrapper-data.txt
ln -s mpicc-vt-wrapper-data.txt mpicc-gcc-4.7-vt-wrapper-data.txt
ln -s mpic++-vt-wrapper-data.txt mpic++-gcc-4.7vt--wrapper-data.txt

ln -s mpicxx-vt-wrapper-data.txt mpicxx-gcc-4.7-vt-wrapper-data.txt
ln -s mpif77-wrapper-data.txt mpif77-gcc-4.7-wrapper-data.txt
ln -s mpif90-wrapper-data.txt mpif90-gcc-4.7-wrapper-data.txt
ln -s mpicc-wrapper-data.txt mpicc-gcc-4.7-wrapper-data.txt
ln -s mpic++-wrapper-data.txt mpic++-gcc-4.7-wrapper-data.txt
ln -s mpicxx-wrapper-data.txt mpicxx-gcc-4.7-wrapper-data.txt


5. Compile FFT using your new GCC
cd ~/tmp
wget ftp://ftp.fftw.org/pub/fftw/fftw-3.3.2.tar.gz
tar xvf fftw-3.3.2.tar.gz

cd fftw-3.3.2/
./configure --enable-float --enable-mpi --enable-threads --with-pic --prefix=/share/apps/libs/fftw-3.3.2-gcc47/single CC=gcc-gcc-4.7 FC=gfortran-gcc-4.7 CPP=cpp-gcc-4.7 MPIF90=mpif90-gcc-4.7 F77=gfortran-gcc-4.7 MPICC=mpicc-gcc-4.7 MPIF77=mpif77-gcc-4.7

make
make install
make check

--------------------------------------------------------------
         FFTW threaded transforms passed basic tests!
--------------------------------------------------------------
..
Executing "mpirun -np 1 ..
..
make[3]: *** [check-local] Error 1
..

That mpirun won't work isn't that surprising since it's still point to /opt/openmpi/bin instead of our mpirun-gcc-4.7

make distclean
./configure --disable-float --enable-mpi --enable-threads --with-pic --prefix=/share/apps/libs/fftw-3.3.2-gcc47/double CC=gcc-gcc-4.7 FC=gfortran-gcc-4.7 CPP=cpp-gcc-4.7 MPIF90=mpif90-gcc-4.7 F77=gfortran-gcc-4.7 MPICC=mpicc-gcc-4.7 MPIF77=mpif77-gcc-4.7

make
make install
make check
--------------------------------------------------------------
         FFTW threaded transforms passed basic tests!
--------------------------------------------------------------
...followed by the same error as above.
It's fine.

6. Optional: Compile openblas using your new GCC
cd /share/apps/tools/gcc/binutils/bin
ln -s ar-gcc-4.7 gcc-ar

cd ~/tmp
wget http://nodeload.github.com/xianyi/OpenBLAS/tarball/v0.1.1
mv v0.1.1 openblas.tar.gz
tar xvf openblas.tar.gz
cd xianyi-OpenBLAS-e6e87a2/
wget http://www.netlib.org/lapack/lapack-3.4.1.tgz

export LD_LIBRARY_PATH=/share/apps/tools/gcc/gmp/lib:/share/apps/tools/gcc/mpc/lib:/share/apps/tools/gcc/mpfr/lib

make all BINARY=64 CC=gcc-gcc-4.7 FC=gfortran-gcc-4.7 MPICC=mpicc-gcc-4.7 USE_THREAD=0 INTERFACE64=1 

make PREFIX=/share/apps/libs/openblas47 install

cp libopenblas_* /share/apps/libs/openblas47/lib
cd /share/apps/libs/openblas47/lib
ln -s libopenblas_nehalem-r0.1.1.so libopenblas.so.1
ln -s libopenblas.so.1 libopenblas.so
ln -s libopenblas.so libopenblas.so.0
ln -s libopenblas_nehalem-r0.1.1.a libopenblas.a

7. Compile Quantum Espresso using your new GCC
sudo mkdir /share/apps/QE
sudo chown $USER /share/apps/QE
mkdir /share/apps/QE/lapack-3.2

mkdir ~/tmp/QE
cd ~/tmp/QE

wget http://qe-forge.org/frs/download.php/211/espresso-5.0.tar.gz
wget http://qe-forge.org/frs/download.php/214/PWgui-5.0.tgz
wget http://qe-forge.org/frs/download.php/204/xspectra-5.0.tar.gz

Edit environmental_variables
PREFIX=/share/apps/QE
TMP_DIR=/tmp/QE
PARA_PREFIX="mpirun-gcc-4.7 -n 8"

Time to configure and compile:
cd ~/tmp/QE
tar xvf espresso-5.0.tar.gz
cd espresso-5.0/
cp lapack-3.2 -R /share/apps/QE/
cp BLAS -R /share/apps/QE/

Create a script called compile.sh:

make clean
export PATH=""
export PATH="/usr/bin:/usr/sbin:/bin:/sbin:/usr/local/ecce/apps/scripts/share/apps/pvm/pvm3/bin/LINUX64:/share/apps/libs/openmpi47/bin:/share/apps/nwchem/nwchem-6.1/bin/LINUX64:/share/apps/sinfo/bin:/share/apps/sinfo/sbin:/share/apps/gromacs/bin:/share/apps/cmake/bin:/share/apps/tools/babel/bin:/share/apps/tools/htop/bin:/share/apps/tools/xmgrace/grace/bin:/share/apps/tools/rasmol/src:/share/apps/tools/strace/bin:/share/apps/tools/gcc/gcc47/bin:/share/apps/tools/gcc/binutils/bin"
which mpif90
read -p "press any key"
export CC=gcc-gcc-4.7
export FC=gfortran-gcc-4.7
export MPIF90=mpif90-gcc-4.7
export MPIF77=mpif77-gcc-4.7
export F77=gfortran-gcc-4.7
export F90=gfortran-gcc-4.7
export CPP=cpp-gcc-4.7
export CXX=g++-gcc-4.7
export CFLAGS=""
export DFLAGS="-DFFT_FFTW3"
export CPPFLAGS="-I/share/apps/tools/gcc/mpc/include -I/share/apps/tools/gcc/gmp/include -I/share/apps/tools/gcc/mpfr/include -I/share/apps/tools/gcc/gcc47/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/include -I/share/apps/libs/openmpi47/include -I//share/apps/tools/gcc/gcc47/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/include"
export LDFLAGS="-L/share/apps/tools/gcc/gcc47/lib -L/share/apps/tools/gcc/gcc47/lib64 -L/share/apps/tools/gcc/gcc47/lib/gcc/x86_64-unknown-linux-gnu/4.7.1 -L/share/apps/tools/gcc/gmp/lib -L/share/apps/tools/gcc/mpc/lib -L/share/apps/tools/gcc/mpfr/lib -L/share/apps/libs/openmpi47/lib -L/lib64 -lc"
#export BLAS_LIBS="-L/share/apps/libs/openblas47/lib -lopenblas" 
export BLAS_LIBS="/share/apps/QE/BLAS/blas.a"
export LAPACK_LIBS="/share/apps/QE/lapack-3.2/lapack.a"
export FFT_LIBS="-L/share/apps/libs/fftw-3.3.2-gcc47/double/lib -lfftw3 -lfftw3_mpi -lfftw3_threads"
export MPI_LIBS="-L/share/apps/libs/openmpi47/lib -l:/share/apps/libs/openmpi47/lib/libmpi.so"
export LD_LIBRARY_PATH=/share/apps/tools/gcc/gmp/lib:/share/apps/tools/gcc/mpfr/lib:/share/apps/tools/gcc/mpc/lib:/share/apps/libs/openmpi47/lib
./configure --prefix=/share/apps/QE/bin|tee conf.log
read -p "Press key to continue"
cd PW
make |tee make.log
cd ../
make all |tee makeall.log

Then run it using

sh compile.sh

Which gives:

--------------------------------------------------------------------
ESPRESSO can take advantage of several optimized numerical libraries
(essl, fftw, mkl...).  This configure script attempts to find them,
but may fail if they have been installed in non-standard locations.
If a required library is not found, the local copy will be compiled.

The following libraries have been found:
  BLAS_LIBS=/share/apps/QE/BLAS?blas.a
  LAPACK_LIBS=/share/apps/QE/lapack-3.2/lapack.a
  FFT_LIBS=-L/share/apps/libs/fftw-3.3.2-gcc47/double/lib -lfftw3 -lfftw3_mpi -lfftw3_threads
  MPI_LIBS=-L/share/apps/libs/openmpi47/lib -l:/share/apps/libs/openmpi47/lib/libmpi.so
Please check if this is what you expect.

If any libraries are missing, you may specify a list of directories
to search and retry, as follows:
  ./configure LIBDIRS="list of directories, separated by spaces"

Parallel environment detected successfully.\
Configured for compilation of parallel executables.

For more info, read the ESPRESSO User's Guide (Doc/users-guide.tex).
--------------------------------------------------------------------
configure: success

and more...Once it's over do

cd ~/tmp/QE/espresso-5.0
cp * -R /share/apps/QE/
echo 'export PATH=$PATH:/share/apps/QE/bin' >> ~/.bashrc
source ~/.bashrc

8. Testing PW -- STUCK
export LD_LIBRARY_PATH=/share/apps/tools/gcc/gmp/lib:/share/apps/tools/gcc/mpfr/lib:/share/apps/tools/gcc/mpc/lib:/share/apps/libs/openmpi47/lib:/share/apps/libs/openblas47/lib:/share/apps/tools/gcc/gcc47/lib64
cd /share/apps/QE/PW/examples/example02
./run_example

/share/apps/QE/PW/examples/example02 : starting

This example shows how to use pw.x to compute the equilibrium geometry
of a simple molecule, CO, and of an Al (001) slab.
In the latter case the relaxation is performed in two ways:
1) using the quasi-Newton BFGS algorithm
2) using a damped dynamics algorithm.

  executables directory: /share/apps/QE/bin
  pseudo directory:      /share/apps/QE/pseudo
  temporary directory:   /tmp/QE
  checking that needed directories and files exist...
Downloading O.pz-rrkjus.UPF to /share/apps/QE/pseudo...
Downloading C.pz-rrkjus.UPF to /share/apps/QE/pseudo... done

  running pw.x as: mpirun-gcc-4.7 -n 8  /share/apps/QE/bin/pw.x  

  cleaning /tmp/QE... done
  running the geometry relaxation for CO... from test_input_xml: Empty input file .. stopping
 from test_input_xml: Empty input file .. stopping
 from test_input_xml: Empty input file .. stopping
 from test_input_xml: Empty input file .. stopping
 from test_input_xml: Empty input file .. stopping
 from test_input_xml: Empty input file .. stopping
STOP 2
STOP 2
--------------------------------------------------------------------------
mpirun-gcc-4.7 noticed that the job aborted, but has no info as to the process
that caused that situation.
--------------------------------------------------------------------------
Error condition encountered during test: exit status = 2
Aborting

It's more insidious than that though -- pw.x crashes with "STOP 2" for any type of input.

NOTE: Like on Debian I had segfaults happening when using my own openblas (which works fine with gromacs and nwchem). Hence why I show you how to compile it, yet never use it.

24 July 2012

215. Compiling gcc 4.7.1/gfortran 4.7.1 on Centos 5.6/ROCKS 4.5.3 (and gmp, mpfr, mpc, binutils (ld,as), glibc, libunistring, libtools...)

Update June 2013:
See flakrat's post for a working example: http://flakrat.blogspot.com.au/2013/06/building-gcc-481-on-centos-59.html

I haven't updated this post for a long time, and I haven't been using the GCC I compiled this way. See flakrat's post for an up-to-date working version.

Update(s): This is the first time I compile the GCC and because of this I will like be going back, updating this document over the coming days. Make sure to 1) check back in a week and 2) hit refresh.

Updated (given in Melb./Au time zone): 24/7, 25/7

The reason for this post is the outdated version (4.1) of gcc on our ROCKS 5.4.3/CentOS 5.6 cluster.

I looked at installing GCC 4.4.6 using rpm packages I found online, but I'm not used to the Red Hat way of doing things, and e.g. openmpi-devel was requiring a version of libgomp I wanted to update. Ultimately I got scared of messing up a production cluster and decided that compiling, while slower, is a whole lot safer -- especially if you're not comfortable with the local package manager.

So, here's the alternative route of compiling your own.

I'm really not a friend of CentOS or ROCKS. On the other hand, I freely admit that this is probably in large part due to not being used to it. But...during the course of this compilation my feelings have gone from mild annoyance to active, fiery hate. Mostly it has to do with how old everything is, and the difficult in updating anything in ROCKS.

This is probably my most massive compilation, owing to the number of packages I ended up compiling (a lot of these are probably optional). Guile in particular is very, very demanding.

The order in which things are done is not random


1. Look at 
http://gcc.gnu.org/install/configure.html
http://gcc.gnu.org/install/prerequisites.html

2. Download and untar all the sources
NOTE: you should, if possible, select mirrors based on where you are. However, sometimes you're stuck in a shell and just need to get those files downloaded.

mkdir ~/tmp/gcc
cd ~/tmp/gcc
wget http://www.netgull.com/gcc/releases/gcc-4.7.1/gcc-4.7.1.tar.gz
wget http://www.mpfr.org/mpfr-current/mpfr-3.1.1.tar.gz
wget ftp://ftp.gmplib.org/pub/gmp-5.0.5/gmp-5.0.5.tar.bz2
wget http://www.multiprecision.org/mpc/download/mpc-1.0.tar.gz

tar xvf gcc-4.7.1.tar.gz
tar xvf gmp-5.0.5.tar.bz2
tar xvf mpfr-3.1.1.tar.gz
tar xvf mpc-1.0.tar.gz

That was the easy bit.

I've also set up a directory called /share/apps/tools/gcc/ with proper permissions already (i.e. whoever is doing the compiling should have write access)

3. Build gmp
cd gmp-5.0.5/
mkdir build
cd build/
.././configure --prefix=/share/apps/tools/gcc/gmp --program-suffix=-gcc47
make
make install
make check


4. Build mpfr
cd ../../mpfr-3.1.1/
mkdir build
cd build/
.././configure --prefix=/share/apps/tools/gcc/mpfr --program-suffix=-gcc-4.7 --with-gmp=/share/apps/tools/gcc/gmp
make
make install

Libraries have been installed in:
   /share/apps/tools/gcc/mpfr/lib

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
   - add LIBDIR to the `LD_LIBRARY_PATH' environment variable
     during execution
   - add LIBDIR to the `LD_RUN_PATH' environment variable
     during linking
   - use the `-Wl,-rpath -Wl,LIBDIR' linker flag
   - have your system administrator add LIBDIR to `/etc/ld.so.conf'

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.

make check

It looks like your compile is starting from scratch, but then it ends with:

====================
All 160 tests passed
(1 test was not run)
====================

5. Build mpc
cd ../../mpc-1.0/
mkdir build
cd build/
.././configure --prefix=/share/apps/tools/gcc/mpc --program-suffix=-gcc-4.7 --with-gmp=/share/apps/tools/gcc/gmp --with-mpfr=/share/apps/tools/gcc/mpfr
make
make install
make check

===================
All 64 tests passed
===================


6. Binutils
https://www.gnu.org/software/binutils/
'Often' (judging from forum postings...) you can use an older version of the binutils (ld, as) with a newer version of GCC. However, I need crt1.o when compilicing, it's part of glibc, and glibc requires newer versions of ld and as. So, here we go.
wget http://ftp.gnu.org/gnu/binutils/binutils-2.22.tar.gz
tar xvf binutils-2.22.tar.gz
cd binutils-2.22/
mkdir build
cd build/
.././configure --prefix=/share/apps/tools/gcc/binutils --program-suffix=-gcc-4.7
make
make install
make check

At some point I did:
cd /share/apps/tools/gcc/binutils/bin
ln -s ld-gcc-4.7 ld
ln -s as-gcc-4.7 as
ln -s ar-gcc-4.7 ar
but I don't think it's essential

7. Build gcc
cd ~/tmp/gcc-4.7.1
mkdir build
cd build/
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/share/apps/tools/gcc/gmp/lib:/share/apps/tools/gcc/mpc/lib:/share/apps/tools/gcc/mpfr/lib
.././configure --prefix=/share/apps/tools/gcc/gcc47 --program-suffix=-gcc-4.7 --with-gmp=/share/apps/tools/gcc/gmp --with-mpfr=/share/apps/tools/gcc/mpfr --with-mpc=/share/apps/tools/gcc/mpc LD_FOR_TARGET=ld-gcc-4.7 AS_FOR_TARGET=as-gcc-4.7 --with-ld=/share/apps/tools/gcc/binutils/bin/ld-gcc-4.7 --with-as=/share/apps/tools/gcc/binutils/bin/as-gcc-4.7 --with-ar=/share/apps/tools/gcc/binutils/bin/ar-gcc-4.7 AR_FOR_TARGET=ar-gcc-4.7

make

This takes A LONG TIME.

make install

To do 'make check' you need to have done the compilations of the optional packages (autogen and dependencies) below.
make check

You now have a shiny new compiler.

Using it is another matter. I'm working on that post at the moment...
You may find the following informative:

gcc-gcc-4.7 --print-search-dirs

install: /share/apps/tools/gcc/gcc47/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/

programs: =/share/apps/tools/gcc/gcc47/libexec/gcc/x86_64-unknown-linux-gnu/4.7.1/:/share/apps/tools/gcc/gcc47/libexec/gcc/x86_64-unknown-linux-gnu/4.7.1/:/share/apps/tools/gcc/gcc47/libexec/gcc/x86_64-unknown-linux-gnu/:/share/apps/tools/gcc/gcc47/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/:/share/apps/tools/gcc/gcc47/lib/gcc/x86_64-unknown-linux-gnu/:/share/apps/tools/gcc/gcc47/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../x86_64-unknown-linux-gnu/bin/x86_64-unknown-linux-gnu/4.7.1/:/share/apps/tools/gcc/gcc47/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../x86_64-unknown-linux-gnu/bin/

libraries: =/share/apps/tools/gcc/gcc47/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/:/share/apps/tools/gcc/gcc47/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../x86_64-unknown-linux-gnu/lib/x86_64-unknown-linux-gnu/4.7.1/:/share/apps/tools/gcc/gcc47/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../x86_64-unknown-linux-gnu/lib/../lib64/:/share/apps/tools/gcc/gcc47/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../x86_64-unknown-linux-gnu/4.7.1/:/share/apps/tools/gcc/gcc47/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../lib64/:/lib/x86_64-unknown-linux-gnu/4.7.1/:/lib/../lib64/:/usr/lib/x86_64-unknown-linux-gnu/4.7.1/:/usr/lib/../lib64/:/share/apps/tools/gcc/gcc47/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../x86_64-unknown-linux-gnu/lib/:/share/apps/tools/gcc/gcc47/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../:/lib/:/usr/lib/


8. glibc
cd ~/tmp/gcc
wget http://ftp.gnu.org/gnu/glibc/glibc-2.14.tar.gz
tar xvf blic-2.14.tar.gz
cd glibc-2.14/
mkdir build
cd build/
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/share/apps/tools/gcc/mpc/lib:/share/apps/tools/gcc/mpfr/lib:/share/apps/tools/gcc/gmp/lib
.././configure --prefix=/share/apps/tools/gcc/glibc CC=gcc-gcc-4.7 --with-headers=/usr/src/kernels/2.6.18-238.19.1.el5-x86_64/include
make
make install

Using the current glibc 2.16 requires kernel>2.6.19 which is why I used 2.14. I don't want to fiddle with installing a new kernel on a production system which is shared between several users (and time zones...):
configure: error: GNU libc requires kernel header files from
Linux 2.6.19 or later to be installed before configuring.
The kernel header files are found usually in /usr/include/asm and
/usr/include/linux; make sure these directories use files from
Linux 2.6.19 or later.  This check uses <linux/version.h>, so
make sure that file was built correctly when installing the kernel header
files.  To use kernel headers not from /usr/include/linux, use the
configure option --with-headers.




Optional -- libtool, libunistring, libffi, bdw-gc, autogen and guile

I'm still stuck on Guile.

If you want to run make check on your gcc build, you need autogen, which needs guile, which needs libtool and libunistring

cd ~/tmp/gcc
wget http://ftpmirror.gnu.org/libtool/libtool-2.4.2.tar.gz
tar xvf libtool-2.4.2.tar.gz
cd libtool-2.4.2/
mkdir build
cd build/
.././configure --prefix=/share/apps/tools/gcc/libtool --program-suffix=-2.4.2
make
make install

make check
(this is very slow)
======================
All 122 tests passed
(2 tests were not run)
======================
and
## ------------- ##
## Test results. ##
## ------------- ##

104 tests behaved as expected.
22 tests were skipped.

cd ~/tmp/gcc
wget http://ftp.gnu.org/gnu/libunistring/libunistring-0.9.3.tar.gz
tar xvf libunistring-0.9.3.tar.gz 
cd libunistring-0.9.3/
mkdir build
cd build/
.././configure --prefix=/share/apps/tools/gcc/libunistring
make
make install

make check
====================
All 418 tests passed
====================

cd ~/tmp/gcc
wget ftp://sourceware.org/pub/libffi/libffi-3.0.11.tar.gz
tar xvf libffi-3.0.11.tar.gz 
cd libffi-3.0.11/
mkdir build
cd build/
.././configure --prefix=/share/apps/tools/gcc/libffi
make
make install
cp include -R /share/apps/tools/gcc/libffi/
cp ../src/x86/ffitarget.h /share/apps/tools/gcc/libffi/include/

cd ~/tmp/gcc
wget http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/gc.tar.gz
tar xvf gc.tar.gz
cd gc-7.2/
mkdir build
cd build/
 .././configure --prefix=/share/apps/tools/gcc/bdw-gc
make

make check
===================
All 10 tests passed
===================

wget ftp://ftp.gnu.org/gnu/guile/guile-2.0.6.tar.gz
tar xvf guile-2.0.6.tar.gz
cd guile-2.0.6
mkdir build
cd build/
.././configure --prefix=/share/apps/tools/gcc/guile --with-libltdl-prefix=/share/apps/tools/gcc/libtool --with-libgmp-prefix=/share/apps/tools/gcc/gmp --with-libunistring-prefix=/share/apps/tools/gcc/libunistring LIBFFI_CFLAGS=-I/share/apps/tools/gcc/libffi/include LIBFFI_LIBS=-L/share/apps/tools/gcc/libffi/lib BDW_GC_CFLAGS=-I/share/apps/tools/gcc/bdw-gc/include BDW_GC_LIBS=-L/share/apps/tools/gcc/bdw-gc/lib
make

Stuck:

../.././libguile/finalizers.c:167: error: static declaration of 'GC_set_finalizer_notifier' follows non-static declaration
/share/apps/tools/gcc/bdw-gc/include/gc/gc.h:177: error: previous declaration of 'GC_set_finalizer_notifier' was here
make[3]: *** [libguile_2.0_la-finalizers.lo] Error 1
make[3]: *** Waiting for unfinished jobs....
make[3]: Leaving directory `/home/me/tmp/gcc/guile-2.0.6/build/libguile'
make: *** [all] Error 2


wget http://ftp.gnu.org/gnu/autogen/rel5.16/autogen-5.16.tar.gz
tar xvf autogen-5.16.tar.gz
cd autogen-5.16/
mkdir build
cd build/






Errors:
checking for x86_64-unknown-linux-gnu-gcc... /home/me/tmp/gcc/gcc-4.7.1/build/./gcc/xgcc -B/home/me/tmp/gcc/gcc-4.7.1/build/./gcc/ -B/share/apps/tools/gcc/gcc47/x86_64-unknown-linux-gnu/bin/ -B/share/apps/tools/gcc/gcc47/x86_64-unknown-linux-gnu/lib/ -isystem /share/apps/tools/gcc/gcc47/x86_64-unknown-linux-gnu/include -isystem /share/apps/tools/gcc/gcc47/x86_64-unknown-linux-gnu/sys-include
checking for suffix of object files... configure: error: in `/home/me/tmp/gcc/gcc-4.7.1/build/x86_64-unknown-linux-gnu/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
make[2]: *** [configure-stage1-target-libgcc] Error 1
make[2]: Leaving directory `/home/me/tmp/gcc/gcc-4.7.1/build'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/home/me/tmp/gcc/gcc-4.7.1/build'
make: *** [all] Error 2

Solution: export LD_LIBRARY_PATH to include the mpc, mpfr and gmp lib dirs (see above)

Links to this post:
http://blog.naver.com/PostView.nhn?blogId=myunggyu&logNo=60173986972&categoryNo=0&parentCategoryNo=0&viewDate&currentPage=1&postListTopCurrentPage=1&userTopListOpen=true&userTopListCount=30&userTopListManageOpen=false&userTopListCurrentPage=1
http://flakrat.blogspot.com/2013/06/building-gcc-481-on-centos-59.html