Fedora Core 5 Compiler Problems

From Fedora Core 4 onwards the default compiler is gcc 4.0. Starting from gcc 4.0 the new Fortran native compiler gfortran is introduced. The gfortran compiler is the GNU implementation of the new standard Fortran 95 ISO/IEC 1539-1997 that contains most features both for Fortran 90 and FORTRAN 77.

As the use for gfortran may give rise to compilation problems for geant3, alternate solutions are needed to create a working version of aliroot. At present the simplest solution we found with Fedora Core 5 is the installation of the compatibility suite including the compat-gcc-32 compilers.

We performed our tests for x86_64 architecture using the following resources:

• aliroot versions:

  root        v5-11-06
  geant3      v1-5
  aliroot     v4-04-Release [pro]
  

• cpu and kernel:

  CPU AMD Athlon(tm) 64 Processor 3400+ 2Gb RAM.
  Test on Fedora Core release 5 (Bordeaux) kernel 2.6.16-1.2080_FC5
  for x86_64
  

• compatibility:

  $ rpm -qf /usr/bin/g77
  compat-gcc-32-g77-3.2.3-55.fc5
  

• Fedora Core 5 release compilers:
  gcc/g++ gcc version 4.1.0 20060304 (Red Hat 4.1.0-3)
  g77 gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-55.fc5)

You can verify compiler installation with the commands:

$ gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
--with-cpu=generic --host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.0 20060304 (Red Hat 4.1.0-3)

and for g77:

$ g77 -v
Reading specs from /usr/lib/gcc-lib/x86_64-redhat-linux/3.2.3/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--enable-languages=c,c++,f77 --disable-libgcj --host=x86_64-redhat-linux
Thread model: posix
gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-55.fc5)
\begin{verbatim}
$ file /usr/bin/g77
/usr/bin/g77: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for
GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9,
stripped

Compilation terminated successfully, but the linker step aborted with shared libraries errors in geant:

$ tail Gerr.geant3-v1-5
/usr/bin/ld: cannot find -lg2c
collect2: ld returned 1 exit status
gmake: ***
[/home/luvisetto/Alice/AliRoot/geant3-v1-5/lib/tgt_linuxx8664gcc/libgeant321.so]
Error 1

and in aliroot

$ tail Aerr.aliroot-pro-v4-04-Release.1
/usr/bin/ld: cannot find -lg2c
collect2: ld returned 1 exit status
gmake[1]: *** [bin/tgt_linuxx8664gcc/dateStream] Error 1
gmake: *** [default] Error 2

Both link steps fail complaining for missing library g2c. Library g2c is the Fortran 77 shared library needed to run Fortran 77 dynamically linked programs. The library is no longer needed with the new family of Fortran (native) compilers like g95.
To correct the error, we searched first of all for the shared version of g2c in /usr/lib*:

$ locate libg2c.so
/usr/lib/gcc-lib/x86_64-redhat-linux/3.2.3/libg2c.so
/usr/lib/gcc-lib/x86_64-redhat-linux/3.2.3/32/libg2c.so
/usr/lib64/libg2c.so.0
/usr/lib64/libg2c.so.0.0.0

The libary exists, thus we printed the ldconfig cache to find out whether and which g2c library was present for ld:

$ /sbin/ldconfig -p | grep g2c
        libg2c.so.0 (libc6,x86-64) => /usr/lib64/libg2c.so.0

As the library is the one stored at /usr/lib64/ and not in /usr/lib/, to solve the problem we need a link in /usr/lib/:

$ su
# ln -s /usr/lib64/libg2c.so.0.0.0 /usr/lib/libg2c.so
# exit
$ ll /usr/lib/*g2c*
lrwxrwxrwx 1 root root 26 Jun 13 09:24 /usr/lib/libg2c.so -> /usr/lib64/libg2c.so.0.0.0

Now the linker terminates successfully and we can run simulation tests with increasing values of nParticles up to 100000.
The main drawback of this solution is the need of root privileges to create the symbolic link.