On Tue, Dec 11, 2012 at 12:07:17PM -0600, Kenneth Herner wrote:
> 
> I am attempting to build root 5.28 as part of testing some legacy software, and for maximum compatibility I would like to use gcc/g++/g77 3.4 when building. I've installed all of the appropriate compatibility rpms on two machines, one running SLF 5.7 and the other 6.3. When I build on the SLF 5.7 machine everything works fine. When I do the same thing on the SLF 6.3 machine it works until almost the end, where I get the following error:
> 
> g77 -m32 -O2  -o bin/g2root main/src/g2root.o \
>                    -Llib lib/libminicern.so \
>                    /usr/lib/gcc/x86_64-redhat-linux/3.4.6/libfrtbegin.a /usr/lib/gcc/x86_64-redhat-linux/3.4.6/32/libg2c.so -lnsl -lm -ldl  -pthread   -rdynamic
> 
> /usr/lib/gcc/x86_64-redhat-linux/3.4.6/libfrtbegin.a: could not read symbols: File in wrong format
>


So you are trying to cross-compile 32-bit ROOT on a 64-bit machine.

I confirm that such cross-compilation works correctly for most recent
versions of ROOT, but older versions had problems in the Makefile and in the configure scripts.

The error you report seems like one of those problems - the Makefile thinks it is doing a 32-bit
compilation ("-m32" on the g77 command line), but supplies a 64-bit fortran runtime
library (/usr/lib/gcc/x86_64-redhat-linux/3.4.6/libfrtbegin.a)

To begin with, you need to find the 32-bit version of the same library, then you need
to convince the Makefile to use it (hint: vi the Makefile).

Also check that you are doing the cross compilation correctly: do "setarch i386" before
anything to fool the ROOT build scripts into thinking that they are running on a 32-bit machine.

Good luck.

K.O.



> collect2: ld returned 1 exit status
> make: *** [bin/g2root] Error 1
> 
> When I do rpm -qf /usr/lib/gcc/x86_64-redhat-linux/3.4.6/libfrtbegin.a I get
> 
> compat-gcc-34-g77-3.4.6-19.el6.x86_64
> 
> for SLF6, and
> 
> compat-gcc-34-g77-3.4.6-4.1.x86_64
> 
> for SLF 5.7. Are there any changes in this package that would cause an error such as the one above? It looks like it's the same version of the compiler, but something important must have changed between version 4 and 19. Does anyone have an idea regarding a workaround?
> 
> Many thanks,
> 
> Ken

-- 
Konstantin Olchanski
Data Acquisition Systems: The Bytes Must Flow!
Email: olchansk-at-triumf-dot-ca
Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada