Hi, Thanks to you and Connie for your suggestions. Indeed I had the needed 32-bit libraries already installed; the problem was in the root Makefile as you had also suggested:
ifeq ($(F77),g77) LIBFRTBEGIN := $(shell $(F77) -print-file-name=libfrtbegin.a) F77LIBS := $(LIBFRTBEGIN) $(F77LIBS) endif That will give you the path to the 64-bit library even if you have configured for running in 32-bit mode. Changing to the following worked: ifeq ($(F77),g77) ifeq ($(ARCH),linux) LIBFRTBEGIN := $(shell $(F77) -m32 -print-file-name=libfrtbegin.a) F77LIBS := $(LIBFRTBEGIN) $(F77LIBS) else LIBFRTBEGIN := $(shell $(F77) -print-file-name=libfrtbegin.a) F77LIBS := $(LIBFRTBEGIN) $(F77LIBS) endif endif Cheers, Ken On Dec 11, 2012, at 1:51 PM, Konstantin Olchanski <[email protected]> wrote: > On Tue, Dec 11, 2012 at 01:37:37PM -0600, Connie Sieh wrote: >> On Tue, 11 Dec 2012, Kenneth Herner wrote: >> >>> Hello, >>> >>> 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 >>> collect2: ld returned 1 exit status >> >> A common reason for the above error is using a 32bit library/archive >> when a 64 bit one is expected and vice versa. >> >> A default install for SL5 installs many i386 packages in addition to >> the x86_64 packages for a x86_64 install. On SL6 only x86_64 >> packages are installed. >> > > I routinely cross-compile 32-bit ROOT on 64-bit machines, and indeed lack > of 32-bit devel packages in the default installation is a minor difficulty. > > Here is the complete list of packages I have to install for building 32-bit > ROOT (and some other packages) > > yum install --skip-broken giflib.i386 giflib.i686 giflib.x86_64 > compat-libf2c-34.i386 compat-libf2c-34.i686 mysql-devel mysql-devel.i686 > openssl-devel.i686 sysstat "libusb-devel*" unixODBC-devel unixODBC-devel.i686 > postgresql-devel libxml2-devel libXpm-devel libgfortran libstdc++-devel.i386 > libstdc++-devel.i686 git compat-readline43 "graphviz*" dcap "zlib-*.i686" > "libXext-*.i686" "libXtst-*.i686" "tigervnc*" telnet glibc"*" > glibc-static.i686 freetype.i686 fontconfig.i686 libpng.i686 libXrender.i686 > strace "fftw*" libpng "freetype*" xpdf "xemacs*" tkcvs xterm mutt "*g77*" joe > "libXmu*" glibc-devel.i686 libX11-devel.i686 libXpm-devel.i686 > libXft-devel.i686 mysql-devel.i686 dcap-devel dcap-devel.i686 gsl-devel > gsl-devel.i686 pcre-devel pcre-devel.i686 fontconfig-devel.i686 > freetype-devel.i686 libpng-devel.i686 libjpeg-devel.i686 libgfortran.i686 > libxml2-devel.i686 h5py gd-devel gd-devel.i686 readline-devel.i686 > ncurses-devel.i686 libXdmcp.i686 xorg-x11-fonts"*" rdesktop minicom xfig"*" > > (Note that this list is "historical" - packages are added to but never > removed from this list) > > http://www.triumf.info/wiki/DAQwiki/index.php/SLinstall > > The reason for cross-compilation is that we have: > a) proprietary "32-bit only" libraries > b) 32-bit VME-form-factor computers that do not have sufficient memory for > building ROOT & similar. > > And of course cross-compilation of ARM binaries is on the way... > > K.O. > > > > > >> -Connie Sieh >> >>> 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
